rplante at poplar.ncsa.uiuc.edu
Thu Jun 7 06:55:50 PDT 2007
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
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.
> is illegal and should be
No, since there is no global Capability element. This should be (for
> 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,
More information about the registry