rplante at ncsa.uiuc.edu
Fri Jun 25 08:39:58 PDT 2004
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
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.
> > 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">
More information about the registry