NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi John, This version resolves all of my major issues vis-a-vis dataset/collection semantics. I only have two significant comments: 1) I see that DataType/MetadataType/ServiceType definitions are unchanged. We've already been over some of the issues here so I won't restate them - I assume dealing with this is being postponed to a future revision. 2) I don't see the justification for the "property" tag. It seems like this is a duplication of basic XML functionality. I.e. if you want to add THREDDS-parseable information about dataset elements later on, you can just add XML attributes to the dataset tag, as you have done for the "dataType" and "authority" fields. So I'm not sure what you gain by adding your own generic tag whose "meaning" is that it is really just an attribute. My remaining issues with the DTD are all just details that I can live with. So that's it.. - Joe John Caron wrote: > heres another strawman, incorporating our latest discussions: > > http://www.unidata.ucar.edu/projects/THREDDS/xml/InvCatalog.0.6d.dtd > > Recent changes: > > 1) Collections as datasets. Ethan and I think the cleanest way to allow> "collections as datasets" is to allow nested datasets. Collections remain
> just groups of datasets. A Collection as a dataset is done as a dataset with > nested datasets. Nested dataset elements (Joe's meaning #2) should imply (in> some way we need to clarify better) nested datasets (Joe's meaning #1 and
> #3). > > 2) allow compound services again. I have talked myself into that these will > be often useful. > > 3) services are now contained within any collection, rather than having to> be all in the top catalog element. They are scoped by the collection they
> are in (so we no longer use ID, since those are global). This makes a > catalogRef have (almost) the same semantics as a collection. > > 4) a catalog now only has exactly one collection element. (i considered > eliminating catalog but i think its better this way). > > 5) "attribute" changed to "property" (tired of saying "the attribute > attribute") > > 6) access element can specify an absolute URL with a serverType -or- a > reletive URL with a serverID. > > >> Unless I get a barrage of objections, I will document this in more detail
> ASAP. I will be gone for a week starting next Tuesdy, so Ethan will continue > the conversation as needed. Hopefully, we can converge soon and take a > break! I think I have incorporated all the good ideas i have heard in this> discussion. Have I left out something, or do you think any feature is not
> worth the complexity? > > > > -- Joe Wielgosz joew@xxxxxxxxxxxxx / (707)826-2631 --------------------------------------------------- Center for Ocean-Land-Atmosphere Studies (COLA) Institute for Global Environment and Society (IGES) http://www.iges.org
thredds archives: