VOResource v1.0 IWD

[Aurelien Stebe]

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