elementFormDefault="unqualified"

[Guy Rixon]

Ray,

thanks for the clarification.

What I've been doing to day is making a tiny schema to define a list  
of vr:Capability as a global element, in order that my VOSI  
implementation return something that can be schema-checked. It looks  
like this:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
   targetNamespace="http://www.astrogrid.org/Capabilities"
   elementFormDefault="qualified"
   attributeFormDefault="unqualified"
   xmlns:tns="http://www.astrogrid.org/Capabilities"
   xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
   xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0">

   <xs:import namespace="http://www.ivoa.net/xml/VOResource/v1.0"  
schemaLocation="http://software.astrogrid.org/schema/vo-resource- 
types/VOResource/v1.0/VOResource.xsd"/>

   <xs:element name="capabilities">
     <xs:complexType>
       <xs:sequence>
         <xs:element name="capability" form="unqualified"  
type="vr:Capability" minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
     </xs:complexType>
   </xs:element>


</xs:schema>


and lets me say

<cap:capabilities xmlns:cap="...">
   <capability>...</capability>
   ...
</cap:capabilities>

My checking tool (oXygen 8) needs a namespace on the root element to  
know where to start checking.

Note how I've had to do the form: qualified by default on the schema  
as a whole and unqualified explicitly on the local element inside the  
complex type. If I put elementFormDefault="unqualified" then the  
schema checker rejects cap:capability, so _it_ think the default  
applies to global elements. Maybe it's wrong.

I can handle this now that I know what is going on, but it took me  
two days to work it out. Can we maybe draft some explanation or  
guidelines for implementors (of did you do that already?).

On 7 Jun 2007, at 14:55, Ray Plante wrote:

> 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