Re: namespaces and schemaLocation

Martin Gudgin wrote:
> 
> <snip/>
> 
>
> Note that in the above schema both 'foo' and 'baz' are in the
> http://example.org/something namespace while 'bar' is in no namespace
> because all local element and attribute decls are, by default, in no
> namespace.

The phrase "in no namespace" has often seemed to be a source of 
confusion, and I'd suggest it might be avoided in developing 
tutorial material.

A useful analogy might be with a language that has packages that
contain class definitions that contain field definitions.  Are the
class names "in" the package?  Are the field names "in" the package?
In one sense, they certainly all are - however, they are within what
Schema would call different "symbol spaces" within the package (to
avoid confusion with what other languages would call "name spaces",
since "namespace" has a special sense in XML more analogous to
"package space").

So one way of explaining the schema situation would be as follows:

Schema components may be "associated with" a target namespace, or
with no target namespace (like an anonymous package).  This is 
orthogonal to the question of whether the components have top-level 
names ("global" - slight misnomer, since they are not globally unique), 
or are in a local symbol space like field names, which only 
have to be unique in the symbol space of fields within their class.

1A) For simple usage in an instance document, you can use an explicit
namespace declaration xmlns:xyz='...' and qualify all your top-level
names from that namespace with the xyz: prefix, and use local names 
without any prefix.

1B) Another style of simple usage is to avoid local element names by
declaring all elements e at the top level, and using the <element 
ref='e'> form to use those top-level element names inside complexType
definitions.  Then (if you wish) you could use a default namespace
declaration xmlns='...' for one of your namespaces, and all your
element names from that namespace can then be unprefixed - but they
are still "qualified" by the namespace that the default xmlns
declaration gives them.

Both the above can be used without worrying about the elementForm
attribute in your schema document, because you are taking the
default which is that local names are "unqualified".

2) For advanced usage (as in the Schema for Schemas), another option
is provided.  This is handy where e.g. you have chosen to have a 
mixture of top-level (ref='e') and local (name='f') element names in 
a complexType definition, and you want to qualify them all the same
way as <xyz:e> and <xyz:f> in the instance (or as <e> and <f> if you
decided to use a default namespace - they are unprefixed,  but
"qualified").  f is still a local name.  This is what you get by
using elementForm="qualified" when declaring f.  (There's no problem
for local attribute names when using default namespace declarations,
since the Namespaces REC made a special case of these, and said that
if they are unprefixed, a default namespace declaration does not
apply to them, so they remain "unqualified".)

The price you pay for this is that <xyz:f> (or <f>) may now refer
not only to different local names in different complexTypes, but may
also refer to a top-level f if you have one associated with the same
targetNamespace.  In other words, qualification no longer tells you
that you are looking at a unique top-level name.


> 
> <snip/>

> No, they are in different namespaces as defined by your schema because, as I
> said in the previous mail, by default local element ( and attribute )
> declarations are in no namespace. You can change this by putting
> form='qualified' on the element declaration or by putting
> elementFormDefault='qualified' on xsd:schema. The former just puts that
> element into the target namespace while the latter puts all local element
> decls into the target namespace ( assuming its not overridden by
> form='unqualified' on a local element decl! )
> 
> >
> > I have the feeling I'm going about this the wrong way. I have been reading
> and rereading those
> > specs, but I find them very hard to decipher. I hope these aren't terribly
> stupid questions! And
> > thanks so much for helping me through them.
> 
> [MJG]
> I think the only thing that is tripping you up is the fact that by default
> local element declarations are in no namespace rather than in the target
> namespace. I would suggest that if in the general case you want all the
> elements in an instance to be in the same namespace then you put
> elementFormDefault='qualified' on your xsd:schema element:
> 
> <schema xmlns='http://www.w3.org/1999/XMLSchema'
>         xmlns:tns='http://example.org/something'
>         targetNamespace='http://example.org/something'
>         elementFormDefault='qualified' >
> 
>   <complexType name='foo'>
>     <element name='bar' type='string' />
>   </complexType>
> 
>   <element name='baz' type='tns:foo' />
> 
> </schema>
> 

This is the "advanced" approach 2) above.  However, you might also 
consider the approaches 1A) and 1B):

1A)  Consistently use local element names inside type definitions;
     qualify only the root element in the instance.

 <schema xmlns='http://www.w3.org/1999/XMLSchema'
         xmlns:tns='http://example.org/something'
         targetNamespace='http://example.org/something'>
 
   <complexType name='foo'>
     <element name='bar' type='string' />
   </complexType>
 
   <element name='baz' type='tns:foo' />
 
 </schema>
 
Then an instance could be written

 <tns:baz  xmlns:tns='http://example.org/something'>
   <bar>The quick brown fox</bar>
 </tns:baz>

and extrapolating to more complicated examples, if the type foo had
more local elements that were of other complex types, all of which
used local names for their elements, tns:baz would still be the
only place that you used a prefix and a qualified name. This would
be true even if the other complex types were defined in other 
namespaces.  Pretty simple if you can live with this convention.

1B)  Consistently use top-level element declarations and use 
     ref='...' inside type definitions; qualify all element names
     in the instance.

 <schema xmlns='http://www.w3.org/1999/XMLSchema'
         xmlns:tns='http://example.org/something'
         targetNamespace='http://example.org/something'>
 
   <element name='bar' type='string' />
   <complexType name='foo'>
     <element ref='bar'/>
   </complexType>
 
   <element name='baz' type='tns:foo' />
 
 </schema>
 
Then an instance could be written either

i)

 <tns:baz  xmlns:tns='http://example.org/something'>
   <tns:bar>The quick brown fox</tns:bar>
 </tns:baz>

or ii)

 <baz  xmlns:tns='http://example.org/something'>
   <bar>The quick brown fox</bar>
 <baz>

This is pretty much the DTD style, where <!ELEMENT bar ...>
defines a top-level name "bar", and use of "bar" in content models is
like a ref to the !ELEMENT declaration.

This is fine as far as it goes, but it doesn't capture genuine
local naming where you want to allow for the possibility that
different uses of the same local element name may have different 
types.

Also the use of explicit qualification as in (i) becomes messy where 
types from different namespaces are used, especially where types 
derived by extension may inherit elements from base types in other
namespaces so that siblings can require different qualifiers.

And the use of default namespace declarations as in (ii) is tricky 
if you want to switch them when encountering a nested element whose
type is defined in a nested namespace.

Hope this helps.

 David