VOResource v1.0 IWD

[Ray Plante]

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. 

> 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).  

> 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.)  

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.  

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.  

> 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.  

> 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.

> 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.  

cheers,
Ray