On the surface not maintaining a list of services would appear to make things more extensible and open, but I suspect it could render the service specifications somewhat unmanageable without additional metadata and registries, such as WSDL and UDDI. Implementations could tend toward one-to-one mappings of specialized services and clients without controlled and verifiable lists, but maybe that is ok. -----Original Message----- From: John Caron [mailto:address@hidden Sent: Wednesday, May 15, 2002 6:28 PM To: address@hidden Subject: Re: New Catalog XML Draft thanks ken, i knew i was fudging by not listing out the various services. what do you think of Joe's idea of not trying to list the services, but leaving it open? I guess the "XML thing" to do would be to use a URI, like how namespaces work. ----- Original Message ----- From: "Ken Keiser" <address@hidden> To: "John Caron" <address@hidden>; <address@hidden> Sent: Tuesday, May 14, 2002 2:08 PM Subject: RE: New Catalog XML Draft > This looks like a good attempt to handling the issue of multiple access interfaces for the same dataset and it seems fairly straightforward to me. One comment, I don't think OpenGIS is a service type. Rather specific OpenGIS services would be individual service types - such as WMS, WCS, WFS, etc. The service type specification implies the resulting output of the service and how to communicate with it. In the same sense that specifying type=DODS lets a DODS client know that it can then get data from the described server, then type=WCS would let a WCS client know that the server is compatible. > > -----Original Message----- > From: John Caron [mailto:address@hidden > Sent: Tuesday, May 14, 2002 1:28 PM > To: address@hidden > Subject: New Catalog XML Draft > > > Proposed changes to the THREDDS catalog format are at: > > http://www.unidata.ucar.edu/projects/THREDDS/tech/InvCatalog6.html > > The current format is documented at: > > http://www.unidata.ucar.edu/projects/THREDDS/tech/InvCatalog5.html > > > Summary of changes: > a.. add <attribute> elements to collection, dataset, service > b.. rename "server" element to "service". > c.. add new service types: (DODS | ADDE | NetCDF | Catalog | FTP | OpenGIS > | WSDL | Other) . > d.. allow multiple services per dataset: add <access> child element of > dataset, where you list any number of services for that dataset, and add > <serviceList> element so you can define a list of services. "serviceId" now > refers to either a service or a serviceList. Use a serviceList when the same > dataset urlPath can be appended onto all service bases. > e.. generalize <datasetDescRef> element to <metadataRef>, where > "DatasetDesc" is one of several metadata types. proposed types: (DatasetDesc > | DublinCore | DIF | ADN | FGDC | LAS | Other) > f.. add "ID" and "alias" attributes to dataset, so that a dataset can be > an alias to another dataset. > Please send comments to me or to this list. > >
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.