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).
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.
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
Received on 2007-06-07Z15:56:42