VOResource v1.0 IWD

[Arnold Rots]

Ray Plante wrote:
> Hey Arnold
> 
> Thank you, thank you, very much for your careful reading!
> 
> On Thu, 9 Jun 2005, Arnold Rots wrote:
> > In Section 2.2 you define UTCDateTime.  I think it is the only place
> > where you use a union and I wonder whether that is a good choice.
> > It is obviously tempting, but my impression is that code generators
> > are not universally happy with it since it makes for a rather
> > indeterminate polymorphism.
> 
> I am concerned about this for the same reason.  This definition was lifted 
> from the OAI schema which was addressing the same requirement: to support 
> dates either with or without the hms part.  This is one of the things we 
> need to test with existing code generators.
> 
> I've done a little bit of this using Axis' wsdl2java.  I was concerned it 
> would create 2 internal data fields in the UTCDateTime type (one for each 
> type in the union), but it only created one of type java.util.Calendar.  
> I haven't actually tested the serialization/deserialization yet, so some 
> questions remain.  We'll need to see what the .Net tools do with it as 
> well. 

Well, yes, I have always thought it most unfortunate that datetime
does not support ISO 8601 when it comes to truncation, i.e.,
yyyy[-mm[-dd[Thh[:mm[:ss[.sss]]]]]]

> 
> > As part of that union you define UTCDateTimeZ.  I would advise against
> > it.  The "Z" option has explicitly been excluded from STC and from
> > FITS since the whole time zone philosophy in ISO 8601 is totally
> > inadequate for astronomical purposes.  I am aware that that does not
> > play a role here, but I would suggest that consistency within the VO
> > is more important.  Therefore I would suggest to drop the Z and assume
> > UTC by implication (it's in the type name anyway).
> 
> Your point about FITS (with STC following suit) is an interesting one.  I 
> would be happy to drop the forcing of the use of the trailing Z.  
> 
> One argument for keeping the Z (which I don't find very compelling given 
> the FITS standard choice) is that this is how you encode a UTC using the 
> ISO 8601 standard.  By forcing the use of Z you disallow the use of 
> timezones and make it clear (to outside users, parsers) that this is a UTC 
> value.  Arguably, the dates we're talking about here are not 
> intended to be astronomical in precision, so the 8601 should be adequate 
> here.  Other comments, anyone?
> 
> > Ah well, I have to make a comment on the bullet in Section 2.3 that
> > deals with substitution groups.  xsi:type is not completely
> > functionally equivalent to substitution groups; there are a few
> > differences.  
> 
> So this is our on-going debate.  By "functionaly equivalent", I mean that 
> any content (or control of that content) of a node represented by an 
> element in a substitution group can be represented with an element and an 
> xsi:type.  That is, except for the element name and whether there's an
> xsi:type, everything else about the element is exactly the same.  
> 
> > I know you have reservation about substitution groups, and I share
> > most of them, but there are certain things that one can do with SGs
> > that xsi:type does not allow.
> 
> So my challenge to you would be to come up with an example of rendering 
> content that you can do with one technique but not the other (that 
> differs beyond the element name and whether there is an xsi:type).  

The biggest problem I see with xsi:type is that you can't nest it
because xsi:type cannot be used in a schema.
I'll come back later with a more elaborate example.

> 
> > I am not sure that it is terribly important to make it
> > obvious in the documents that a substitution has been made; I think it
> > is far more important in the schema - and there a substitution group
> > provides a more obvious flag.
> 
> In general more eyes--human and software--will look at instance documents 
> than schemas.  (Remember, we went to this from substitution groups based 
> on responses from developers.)  

Um, shouldn't the software also check on the schema when it reads a
document?

> 
> It actually can make a big difference in parsing the document.  Consider a 
> SAX parser operating on a service description.  The interface element must 
> use xsi:type because the Interface type is abstract.  With the xsi:type, 
> you will always be able to find the interface element even if it is of a 
> type you don't support (because you weren't aware of the schema 
> beforehand).  You can still pick out the bits you do recognize.  With 
> substitution groups, if you have a substituting element in there that you 
> don't support, you won't find the interface description.  

The software will find it, since the element in the schema identifies
the substitution group.

> 
> Now an consider XPath.  Suppose that you want some bit of core metadata 
> from the interface, like accessURL.  With the xsi:type technique, you can 
> use an XPath of "resource/interface/accessURL".  With substitution groups 
> you have to resort to "*/*/accessURL" (because resource will always be a 
> point of substitution, too).  Which is more precise?  BTW, this would also 
> break our use of XPath in ADQL when querying the registry, because we have 
> the requirement that it not be necessary for the consumer to parse the 
> XPath; this is only possible if we can restrict ourselves paths 
> that have a one-to-one mapping to locations in an XML document.  

I can't really comment on XPath.

> 
> > Near the end of 2.3.1 you talk about sharpening the meaning of a
> > vr:Resource.  To me, "sharpening" conjures associations with
> > "restriction", not "extension" or just a name change.  
> 
> Perhaps different wording would be helpful.  Suggestions?  In OO 
> modeling, When you create a derived class, you are creating something more 
> specific from the more general parent class.  It shouldn't matter (in 
> the XML case) if this is by extension or restriction.  That notion of 
> refining is what I'm trying to capture there.  

I thought you were discouraging restriction?

> 
> > And I must say
> > that I am not terribly comfortable with the concept of identical types
> > that supposedly have different properties, implied by the name of the
> > type.
> 
> This is a common technique in OO programming.  For example, it is common 
> in Java to have named interfaces that have no methods.  You tag a class 
> with such an interface to help guide class users on their handling of the 
> class.  The most common example is the interface Serializable.  A more 
> accessible example is in your Zoo class library, you might tag some animal 
> classes as Dangerous.  This doesn't add any new data/methods to the 
> animal, but it is a signal to the visitor class not to feed it.  
> 
> > In 3.1.2, under vr:Date Attributes, I find a value "representative"
> > for "role".  This is mixing apples and oranges.  The coverage is not a
> > part of Curation.  Creation and update are fine, but don't mix in any
> > coverage.
> 
> Date is take from the RM, which states "Typically, 
> Date will be associated with the creation or availability" which 
> correlates with time coverage.  The RM definition is necessarily vague, 
> since its application will depend on the type of resource (DataCollection 
> vs. Service vs. Registry, etc.).  The role attribute provides the ability 
> to be more specific.  
> 
> I'll bring this up Bob.

Please do.  "Creationor availability" does not sound like coverage to me.

> 
> > In 3.1.3, under vr:Content metadata elements, I find source and
> > referenceURL.  Are these really different beasts, other than that one
> > is a URL and the other <somethingElse>?  Or maybe I don't see how one
> > extracts a resource from a bibliographic reference.  
> 
> It is not intended that one extract a resource (in the VO sense) from a
> bib ref.  This source element is most readily applied to a data collection
> (like a catalog) that comes directly from a published result.  This
> element provides the linkage to that literature.
> 
> The referenceURL is specifically about the resource itself--a help page, 
> if you will.  Typically, this will not point to a paper in the literature 
> but rather the home page for the resource.  
> 
> Ultimately, this is a comment for the RM document, which, conveniently, is
> under review.  
> 
> > It struck me that the allowed values for the contentLevel are pretty
> > USA-centric - at least Middle School and Community College are.
> 
> Also, a good comment for the RM review.  
> 
> thanks again!  Particularly for bringing up the substitution group issue.  
> I think we (as a community) have enough experience now to discuss 
> definition style issues.  

Yes, we need a discussion on it.  Not that I am particularly fond of
them.  Their definition in the standard is one thing, but the whole
concept got perverted by the validation rules which result in
contradictory directives and obfuscation.

> 
> cheers,
> Ray
> 
> 
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------