RE: New Catalog XML Draft

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-----
Sent: Wednesday, May 15, 2002 6:28 PM

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 -----
Sent: Tuesday, May 14, 2002 2:08 PM

> 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:caron@xxxxxxxxxxxxxxxx]
> Sent: Tuesday, May 14, 2002 1:28 PM
> To: thredds@xxxxxxxxxxxxxxxx
> Subject: New Catalog XML Draft
> Proposed changes to the THREDDS catalog format are at:
> The current format is documented at:
> 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 |
> |  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"
> refers to either a service or a serviceList. Use a serviceList when the
> 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:
> | 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.