VOResource v1.0 IWD

[Arnold Rots]

What I was trying to do was responding to Ray's challenge to give an
example of a construct that is supported by SG but not by xsi:type,
for the general VO world, not just registry.
This type of more substantial inheritance is important in other areas.

And I reiterate that we ought to drop the Z (it's only one part of
the ISO 8601 standard and there are other parts we don't use, either)
in order to maintain uniformity within astronomy.  Leaving out the Z
does not invalidate the format and is not inconsistent with any
standard.

  - Arnold

Aurelien Stebe wrote:
> Hi,
> 
> I don't really understand what you are trying to do here Arnold.
> You restrict your "container" to an extension of the "element" ?
> So, you want for example to be able to create a "WebBrowserService"
> type which would be the same as "Service" but force its "interface"
> element to the "WebBrowser" type.
> You could do this with an extension of the "resource" type,
> adding an element of "WebBrowser" type.
> (but then I would not advise calling it "interface").
> 
> Anyway, I don't think we need to do that for the registry,
> I even think we shouldn't. So, I'm all for avoiding substitution groups.
> It is specified in the VOResource doc that derivation should be done by 
> "extention".
> I think we could even forbid the use of "restriction" to be sure to 
> always have
> the "resource" basic elements (or the "interface" basic elements).
> 
> Concerning the "dateTime" problem, I think we should keep the "Z",
> as it is the ISO standard and it is how it's used in the OAI interface.
> We can't really change the OAI xsd, so we should copy them
> to have consistency within the registry.
> The use of "union" could be a problem for some, so this should be tested 
> first.
> I don't do any serialization/deserialization, so I would advise to keep 
> it as in the OAI
> for the same reason as above. Let's see how the tests work out.
> 
> By the way, I also noticed a few small typos in the document.
> For example, the "title" and "relationshipType" semantic meanings seem 
> to suffer
> from copy/paste typo, and some "schema definition" extracts still use 
> "xsd:date"
> or are missing "unbounded". Nothing critical really.    :)
> 
> Cheers,
> 
> Aurelien
> 
> 
> Arnold Rots wrote:
> 
> >Hay Ray,
> >
> >OK, here is to your challenge to produce something that can be done
> >with substitution groups (SG) but not with xsi:type.
> >
> >As I said, one major problem is the lack of a nesting mechanism for
> >xsi:type (which could have been solved by allowing xsi:type in schemata).
> >
> >So, very simply, I want to define a generic element, and a generic
> >container for such generic elements.  Now I derive specialized
> >elements from the generic element and a specialized container from the
> >generic container that holds those specialized elements.
> >
> >This leads to the two schemata that I have appended.  The trouble is
> >that the xsi:type version does not validate, whereas the SG one does.
> >At least - I don't see how one can do it for the former.
> >
> >The issue here is retaining the inheritance concept for the container
> >as well as for its contents.
> >
> >Enjoy!
> >
> >  - Arnold
> >
> >--------------------------------------------------------------------------
> >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/
> >--------------------------------------------------------------------------
> >
> >
> >  
> >
> 
--------------------------------------------------------------------------
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/
--------------------------------------------------------------------------