VOResource v0.10

[Gerard Lemson]

Hi Ray (and others)

Was it not decided during the Cambridge meeting that global elements, if
they were to be defined
by the registry group, would not be put in the "type schemas" that Ray
published last week,
but in one or more separate "document schemas", which itself
depend-on/import/include
the type schemas ? As I recall it was claimed that the decision *which*
global elements to support
falls within the realm of the Registry Interface definition.

I think it would also be in that effort that one
would want to make sure that there does not exist a global element named
<conesearch> that has
a type that could be instantiate with an instance of SimpleImageAccess as in
Matthew's example
in http://www.ivoa.net/forum/registry/0406/0982.htm.
Simply defining such an element as
   <xsd:element name="conesearch" type="ConeSearch">
should suffice (unless SimpleImageAccess were a subclass of ConeSearch,
which I hope it isn't).

Cheers

Gerard

--
* Gerard Lemson                       * Tel: +49 (0)89 30000-3316
*
* MPI fuer extraterrestische Physik   * Fax: +49 (0)89 30000-3569
*
* Giessenbachstrasse                  *
*
* Postfach 1312                       *
*
* D-85741 Garching, GERMANY           * email: gerard.lemson at mpe.mpg.de
*


> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org]On Behalf Of
> Ray Plante
> Sent: Friday, June 25, 2004 5:40 PM
> To: registry at ivoa.net
> Subject: Re: VOResource v0.10
>
>
> 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">
>
>