VOResource v0.10

[Ray Plante]

Hi Paul,

On Fri, 25 Jun 2004, Paul Harrison wrote:
> I think that this is at least one argument for defining *some* global 
> elements in these schema (particularly the top level ones) - whilst I 
> think that it was a good refactoring to remove the global element 
> definitions for every type, I think that removing *all* might have gone 
> too far - in that we are giving up a certain degree of control over the 
> instance documents that could well lead to interoperability problems.

Defining a global element does not prevent someone using this trick to 
come up with their own non-standard element, but still have it verify as a 
document.  Whether the global element is defined within VOResource-vX.xsd 
or in an application-specific schema does not give the application any 
more or less control.  

This goes back to a point I've been insisting on back when all elements 
were global.  It's up to the application to choose the root element it 
expects and to verify that is what it has; below that, the parser can take 
over.  

That said, in certain contexts--namely Web Services and OAI--we have a 
little more built-in control.  For example, our current draft registry 
interface WSDL defines the SearchResult message as containing a 
VOResources element which in turn contains one or more Resource elements.  
Sending back a message containing a MySpecialVOAnswer element would be 
caught as an error by the Web Service framework.  

cheers,
Ray

> > On Tue, 22 Jun 2004, Matthew Graham wrote:
> > 
> >>I just want to point out one small consequence of: "According to the XML
> >>Schema standard (Part 1, Sect. 3.3.2, clause 1.2), the use of xsi:type in
> >>the root element is sufficient for defining its type."
> >>I will now be able to legally have a Registry entry:
> >>
> >><conesearch xsi:type="SimpleImageAccess">