Default namespace and attributes

[John L. Clark]

I am curious as to the rationale, and effect, of having default
namespaces not applying (directly) to attributes (see
http://www.w3.org/TR/REC-xml-names/#defaulting). Given an attribute
without a namespace prefix, what is its namespace, if default
namespaces do not apply? Are (either of) prefixed or non-prefixed
attributes correct? For example, are the following equivalent:

<html:br class="foo" xmlns:html="http://www.w3.org/1999/xhtml"/>

and

<html:br html:class="foo"
xmlns:html="http://www.w3.org/1999/xhtml"/>

If so, why? In the former, the class has no (or an empty?) namespace,
while in the latter the class explicitly has the html namespace.

Why would it make sense for attributes to not inherit namespaces as do
elements? What does the specification mean when it says that default
namespaces do not apply /directly/ to attributes?

While I'm on the topic of namespaces, another little thing has been
gnawing at the back of my brain. How can you determine when an
included, namespace-scoped subtree is allowed to be included into the
parent? For example:

<html:html xmlns:html="http://www.w3.org/1999/xhtml"
xmlnsther="http://some.other.namespace/">
<!--Other elements to make the xhtml file valid can be put
here...-->
<other:foo/>
</html:html>

Now, obviously schemas corresponding to the html namespace have no
knowledge of the "other" namespace, and so "other" elements shouldn't
be allowed to arbitrarily populate an "html" tree. Where in the
specifications is this sort of thing discussed? Are subtrees of one
namespace invisible to the parent tree of a different namespace?

Ok, true, this should really have been broken up into two threads, but
I was on a roll, so I felt like just cruisin' through them both.

Take care,

John

--

Please note that you have no evidence that this message was sent by me
<[email protected]>, as it is not digitally signed. If you need to
validate the authenticity of this message, do not hesitate to request
a receipt by responding to this message with the original included.

 

[C. M. Sperberg-McQueen]

I am curious as to the rationale, and effect, of having default
namespaces not applying (directly) to attributes (see
http://www.w3.org/TR/REC-xml-names/#defaulting).

Good question. Consider the following:

- In most XML vocabularies, attributes are defined for
specific element types, not globally for the vocabulary.
- There are, however, exceptions: attributes intended for
use on arbitrary elements (and meaningful even if used
on elements in other namespaces).
- If one takes the term 'namespace' as denoting a pool of
identifiers which each uniquely denote some thing (e.g.
locations in memory or functions), then it's clear that
any XML vocabulary defined by a DTD has several distinct
namespace: one for element types, one for general
entities, one for parameter entities, and so on. Each
element type, in turn, creates a distinct namespace for
its attributes. On this understanding, it's clear that
in the element <foo bar="baz"/>, the element type name 'foo'
and the attribute name 'bar' are in distinct namespaces.
Crucially, the 'bar' attribute of element 'foo' is
quite distinct from the 'bar' attribute of any other element
which might have one: different declaration, possibly
different type, etc.
- It seemed cumbersome but reasonable to require a prefix
on the generic identifier (so we get <n:foo/>), but requiring
a prefix on all the attributes as well seemed problematic:
is it the same namespace? Not if a 'namespace' is a
functional mapping from names to things: the 'bar'
attribute of 'foo' is quite distinct from any 'bar' element
which may be defined in the same vocabulary.
Is it a different namespace? Well, not if we think of
a namespace as containing, or being, a single vocabulary.
And if we did make it a different namespace, then we'd
end up needing a distinct prefix for the attribute namespace
of each element. That, in turn, didn't seem attractive
to anybody.
- If we want to distinguish global from local attributes, it's
convenient to say that local ones are always unprefixed,
and global ones always prefixed.

Given that the Working Group did not have any consensus on the nature
of a 'namespace', nor any consensus about the desirability of greater
clarity on the question, it is perhaps not surprising that we ended up
by agreeing on something which has two rather different
interpretations. We agreed that unprefixed attribute names are not
namespace-qualified (if I may use these terms). Some WG members
believed, I think, that that means "the attributes are not in any
namespace", although there is nothing in the Namespaces spec which
licenses the conclusion that unqualified elements and attributes are
"not in a namespace". (All one can say is that the Namespace mechanism
doesn't associate them with a namespace. Since the spec doesn't
define what a namespace is or constrain it in any way, there isn't
much opportunity for it to say that an unqualified item cannot be
known by out of band methods to be "in" some namespace or other.)
Other WG members believed, I think, that the attributes are "in" the
namespace (or symbol space, as the XML Schema spec calls it)
automatically created for the attributes of each element type; that
namespace is not named, and nothing in the Namespaces Rec says much
about it, but that means nothing in the Namespaces Rec can be used to
prove that it doesn't exist.

So, the main rationale and effect of the rule was to allow the WG to
get the spec out the door before we killed each other or died of
boredom with repetitive arguments.

Given an attribute without a namespace prefix, what is its
namespace, if default namespaces do not apply?

It is not associated by the namespace spec with any namespace. This
means (depending on whom you are talking to) either that it is not in
any namespace or that its association, if any, with a namespace is
achieved through means other than those defined in the namespaces
spec.

Are (either of) prefixed or non-prefixed
attributes correct? For example, are the following equivalent:

<html:br class="foo" xmlns:html="http://www.w3.org/1999/xhtml"/>

and

<html:br html:class="foo"
xmlns:html="http://www.w3.org/1999/xhtml"/>

Not equivalent: the universal names of the two 'class' attributes are
different. One has the pair ("http://www.w3.org/1999/xhtml","class")
as its universal name, the other the pair (NULL, "class"), where NULL
signals the non-existence of a value.

While I'm on the topic of namespaces, another little thing has been
gnawing at the back of my brain. How can you determine when an
included, namespace-scoped subtree is allowed to be included into the
parent? For example:

<html:html xmlns:html="http://www.w3.org/1999/xhtml"
xmlnsther="http://some.other.namespace/">
<!--Other elements to make the xhtml file valid can be put
here...-->
<other:foo/>
</html:html>

Now, obviously schemas corresponding to the html namespace have no
knowledge of the "other" namespace,

How is this obvious? What is to prevent a schema from including
components for both the html and the 'other' namespace? What is to
prevent the content model for the html element from including a
reference to the 'other:foo' element type?

and so "other" elements shouldn't
be allowed to arbitrarily populate an "html" tree. Where in the
specifications is this sort of thing discussed?

The mechanisms by which a schema can comprise components for more than
one namespace are described in the XML Schema specification. The
specifics of what can occur in an HTML element, or in any element in
any namespace, are discussed (if at all) in the documentation for the
namespace in question and defined in the schema documents or DTDs for
that namespace.

Are subtrees of one
namespace invisible to the parent tree of a different namespace?

At the application level, they can be. At the XML level, or the
level of validation using current schema languages, no, not
invisible at all.

I hope this helps.

-C. M. Sperberg-McQueen
World Wide Web Consortium