elementFormDefault="unqualified"

[Ray Plante]

Hi Guy,

Thanks for the query.  The technique for using prefixes is simpler than 
what you describe.  Let me point you to two examples.  (Note: if you view 
these via a browser, be sure you are looking at the page source--Ctl-U in 
Firefox--as the browser sometimes hides some of the namespace related 
attributes).

1) http://www.ivoa.net/internal/IVOA/RegUpgradeToV10/conesearch.xml

    This example shows a stand-alone VOResource record.  You will notice
    that prefixes are only needed...
     o  in the values of xsi:type attributes, and
     o  elements from the STC schema.

    The default namespace is all ready set to no-namespace by default.

2) http://nvo.ncsa.uiuc.edu/cgi-bin/reg10/oai.pl?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://adil.ncsa/targeted/conesearch

    This shows a VOResource record embedded inside an OAI record.  Here the
    "root" element of the VOResource is <ri:Resource>.  One difference is
    the use of xmlns="" on this element to switch to the no-namespace
    namespace; this is needed because the envelope had set the default
    namespace to OAI's.

Now let's look at your example...

On Thu, 7 Jun 2007, Guy Rixon wrote:
> I note that VOResource v0.10 has elementFormDefault="qualified" and 
> VOResource v1.0 has changed to elementFormDefault="unqualified". This appears 
> to mean that types in the schema have the schema's namespace but elements, 
> both local and global, do not. E.g.

Note that there are no global elements in the VOResource schemas except 
for those imported from STC.  elementFormDefault="unqualified" means that 
global elements belong to the namespace (and thus need namespace 
qualification) but local elements do not.

> <vr:Capability>
> <vr:interface>
> ...
>
> is illegal and should be
>
> <vr:Capability>
> <interface>

No, since there is no global Capability element.  This should be (for 
example):

<capability xsi:type="vg:Harvest">
    <interface ...

> Further, this would mean that if I have, say, a document with a 
> locally-defined <interface> and a <vr:Capability>, then I have to put the 
> locally-defined <interface> into an explicit namespace as the IVOA one is 
> using the name in the default namespace.

In the context of a full VOResource record, the techniques shown in my 
first 2 examples can be applied.  If you were just exporting a capability 
record as a stand-alone document, the technique is similar.  If the root 
capability element will have an xsi:type attribute, then it can be left in 
no-namespace (as in ex.1).  If you want/need to have a root element in a 
namespace, define a schema that defines a global Capability element with 
the *type* vr:Capability (as in ex. 2).

> This seems to be backwards to me: 
> I'd expect the formal, IVOA definitions to be in their own namespace and the 
> local, application-specific ones to be in the default namespace.

It's been a common reaction to see elementFormDefault="unqualified" as 
counter intuitive--that somehow we're losing something by not having these 
local elements in our own namespace.  In reality, however, we actually 
lose nothing but gain in a simpler handling of namespaces.  It has no 
bearing on validation--it can still be carried out unambigously.  No one 
has found a case in which it makes a practical difference in how we 
process the data.  There is a potential for confusion if the same element 
name is associated with different types in different parts of the 
document; however, in VOResource, this is not done.

The reason it works well for us is because VOResource defines no global 
elements, only global types.  Thus, no prefixes are needed on VOResource 
elements.  More importantly, you don't need to know which extension schema 
an element comes from in order to assign the proper prefix.  XPath strings 
are similarly much simpler.

hope this helps,
Ray