Hi Joe, thanks for your thoughts; some immediate comments follow. I will also be thinking about these ideas and may have more to say later. ----- Original Message ----- From: "Joe Wielgosz" <address@hidden> To: "Benno Blumenthal" <address@hidden>; "John Caron" <address@hidden>; <address@hidden> Sent: Tuesday, June 04, 2002 3:45 PM Subject: orthogonality (was Re: New attempt) > Benno, John, > > As I am currently immersed in Web-service-think (particularly WSDL, > which seems to basically be a more generalized version of what THREDDS > catalog is attempting for scientific data services) I would propose that > the principle of orthogonality might be a useful tool for deciding on > these issues. > > For an XML design, orthogonality means whether or not a given tag or > attribute represents a distinct concept that is in no case expressible > using existing tags and attributes. > > While a completely orthogonal tag set results in somewhat less succinct > documents than an approach which defines a number of "special case" > tags, the advantage is that it yields the maximum ratio of > expressiveness to schema complexity. > > WSDL is an extreme example of this approach. Unlike them, we may want to > define special-case tags for very common cases to make the > actual documents less unwieldly. > > The purpose of this message is not to suggest exactly which cases these > might be; rather, I am just suggesting we take a look the current and > proposed DTD down from this perspective. I agree that orthogonality is a very important motivation. Related motivation is simplicity (small number of concepts) and concept independence (same meaning wherever a concept is used). The other motivation I have had is: "Make common cases simple and human-readable" For me, attributes are a bit easier to read then contained elements, so this motivation orients me towards the use of attributes, all else being equal. This has also motivated factoring out common information, which reduces repeated information. This has led to: 1) allowing properties to be placed at collection elements which become the defaults for contained datasets. 2) factoring out server/service elements. These are more qualitative and aesthetic judgements, and are rather subjective. None of these can be judged completeley independently, you have to look at the overall effect on readers, writers, APIs, tutorials, etc. > > ------------------- > > A summary of the completely orthogonal concepts I believe we have > introduced thus far (not necessarily named the same as the tags that > currently express the concept): > > service type - a named mechanism for accessing scientific data > > access - a (named?) binding of a URI to a specific service type > > metadata type - a named convention for description of scientific data > > metadata - a (named?) binding of a text fragment to a specific metadata type > > metadata reference - a (named?) binding of a URI to a specific metadata type > > dataset - a named collection of access objects and metadata > > collection - a named collection of datasets > > collection reference - the URI of a THREDDS XML document containing a > collection > > ---------------- > > In contrast, the following concepts are not clearly orthogonal to me: > > service path, server path, collection path, dataset path, suffix - since > they are only used in the context of the access object, they don't > really add meaning - any catalog using these attributes is equivalent to > one without them, which uses absolute uri's for all of its access objects > > compound service / service list - this also doesn't strictly speaking > add meaning since services are only used in the context of access > objects - thus, one access with a compound service type is functionally > equivalent to n access objects with simple service types. > > service subtype - unless the values for this attribute are given > standard meanings, this is equivalent to a named access object. even if > the values do have standard meanings, there still seems to be some > overlap with metadata type. > > catalog, server - if you factor out the path attribute, these are > equivalent to collections > > documentation - equivalent to metadata with a human-readable metadata type > > document - same as documentation, except with the connotation that it is > not critical to interpreting the dataset I think its interesting and important what the ontology is, and I notice some subtle differences in your conceptualization and mine (and also between Benno's and mine). If we can converge on that a bit more, then some of these other issues may be clarified. I think your description above is good, but here are some different perspectives on some of it: I would say the basic objects are datasets and services. Therefore, an access element is a binding of a dataset to a service. The base, path, suffix are first attempts to specify the binding. Metadata are properties of a dataset. Its true that a catalog is just a collection. Its also a container for service elements, but I dont really like that. Even if we keep service elements factored out, it seems better to allow collections to contain service elements, so service elements can be near where they are used. This will probably be useful for large synthetic catalogs. OTOH, a catalog is very much a user-visible object in a way that perhaps an arbitrary collection should not be. So while I am inclined to make a catalog even more like a collection by putting service into collection, I am still inclined to a seperate top-level catalog element at the moment. Ive tried making documentation a metadata subtype. It felt slightly wrong, and I think its because documentation has to do with presentation, while metadata is really properties of the dataset itself. Adding more of the XLink "show" semantics to documentation seem to make it diverge more from metadata. At the cost of adding an extra element, it seems easier to explain with them seperate. Much harder question is the distinction between a dataset and a collection, since a dataset is a collection of data. I have conceptualized it as follows: a dataset is something that can be selected, and then it is processed in a protocol-dependent way. A collection is a protocol-independent mechanism for grouping datasets. > > -------------------- > > One that I am not sure about is the "attribute" tag, since I am not > clear on how this is intended to be used. Is it for the THREDDS parser, > or passed directly to the user? Will there be standardized names and > values for attributes? Im open to suggestions on how it should be used. Right now, Id say it is made available to the client, to the protocol-aware dataset processing, and optionally to the end-user. Therefore it could be the mechanism to make standard extensions in the future without having to change the XML format. > > A reminder, I am not trying to say specifically whether any of these > tags should be kept or dropped. I am merely suggesting that we might > want to focus on tags and attributes that represent orthogonal concepts, > and be a bit more choosy about the rest. > > Also, I would suggest that any proposed extensions that *are* genuinely > orthogonal to the original tag set (although I'm not sure we've had any > thus far) be given special consideration, since by definition, there is > no workaround if they are not included. agree, do yu have anything in mind? > > John, hope this is useful input. very useful, thanks much > > - Joe > >
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.