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.
----- Original Message ----- Sent: Monday, June 10, 2002 12:05 PM > 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. yeah, its pretty much postponed. We have an "Other" type, and I think you can override the ENTITY declarations. Also I am starting to look at XML Schema to see how this can be better done. I think we will have to revisit this. It would be good to accumulate some use cases. > > 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. The problem is that you cant add an XML attribute without changing the DTD. So a property is a way to add non-standard attributes. Im not sure it will be useful. > > My remaining issues with the DTD are all just details that I can live > with. So that's it.. thanks for sticking with it. I am working through a Java object model to see what problems arise.
thredds archives: