Help! Namespace muddle

[kj]

Consider the following XML document:

<?xml version='1.0' encoding='UTF-8'?>
<bar:foo xmlns:bar='someuri'>
<baz/>
</bar:foo>

What namespace does baz belong to? What is this namespace bound
to/associated with? My understanding was that baz above belongs
to some "default default namespace", but I have not been able to
find support in the standard for this. (If it's there I managed
to miss it, and would be thankful if someone would tell me exactly
where.)

Now consider

<?xml version='1.0' encoding='UTF-8'?>
<foo xmlns='someuri'>
<baz xmlns='some_other_uri'>
<frotz/>
</baz>
</foo>

Now, what namespace does baz belong to? 'someuri' or 'some_other_uri'?

In general, in XML code that does not explicitly define any namespaces
(not even default namespaces), what namespace do identifiers belong
to?

Thanks!

kj

 

[Alex Shirshov]

Hello, kj!
You wrote on Tue, 13 Apr 2004 16:20:37 +0000 (UTC):

k> <?xml version='1.0' encoding='UTF-8'?>
k> <bar:foo xmlns:bar='someuri'>
k> <baz/>
k> </bar:foo>

k> What namespace does baz belong to?

It doesn't belong to any.

k> What is this namespace bound to/associated with? My understanding was
k> that baz above belongs to some "default default namespace",

Why do you think so?

k> but I have not been able to find support in the standard for this. (If
k> it's there I managed to miss it, and would be thankful if someone would
k> tell me exactly where.)

k> Now consider

k> <?xml version='1.0' encoding='UTF-8'?>
k> <foo xmlns='someuri'>
k> <baz xmlns='some_other_uri'>
k> <frotz/>
k> </baz>
k> </foo>

k> Now, what namespace does baz belong to? 'someuri' or 'some_other_uri'?

The second, i mean some_other_uri namespace.

k> In general, in XML code that does not explicitly define any namespaces
k> (not even default namespaces), what namespace do identifiers belong
k> to?

They out of any namspace.


With best regards, Alex Shirshov.

 

[Richard Tobin]

What namespace does baz belong to? What is this namespace bound
to/associated with? My understanding was that baz above belongs
to some "default default namespace", but I have not been able to
find support in the standard for this.

The "default default namespace" is no namespace.

-- Richard

 

[Ashmodai]

kj scribbled something along the lines of:

Consider the following XML document:

<?xml version='1.0' encoding='UTF-8'?>
<bar:foo xmlns:bar='someuri'>
<baz/>
</bar:foo>

What namespace does baz belong to? What is this namespace bound
to/associated with? My understanding was that baz above belongs
to some "default default namespace", but I have not been able to
find support in the standard for this. (If it's there I managed
to miss it, and would be thankful if someone would tell me exactly
where.)

Now consider

<?xml version='1.0' encoding='UTF-8'?>
<foo xmlns='someuri'>
<baz xmlns='some_other_uri'>
<frotz/>
</baz>
</foo>

Now, what namespace does baz belong to? 'someuri' or 'some_other_uri'?

'some_other_uri'. The default namespace, i.e. the one with no prefixes,

In general, in XML code that does not explicitly define any namespaces
(not even default namespaces), what namespace do identifiers belong
to?

"no namespace". Even if you use prefixes which haven't been declared to
reference a certain namespace before, the elements using them belong to
"no namespace", or "undefined".
This is explained in the XML Names TR at http://www.w3.org/ as far as I
remember.

A more interesting question is, in:

<foo xmlns="someuri" xmlns:bar="some_other_uri">
<bar:baz qux="some_value"/>
</foo>

What namespace does the attribute qux belong to?
To my understanding it belongs to the bar-namespace (some_other_uri),
although unprefixed.

 

[Philippe Poulard]

kj scribbled something along the lines of:






'some_other_uri'. The default namespace, i.e. the one with no prefixes,



"no namespace". Even if you use prefixes which haven't been declared to
reference a certain namespace before, the elements using them belong to
"no namespace", or "undefined".
This is explained in the XML Names TR at http://www.w3.org/ as far as I
remember.

A more interesting question is, in:

<foo xmlns="someuri" xmlns:bar="some_other_uri">
<bar:baz qux="some_value"/>
</foo>

What namespace does the attribute qux belong to?
To my understanding it belongs to the bar-namespace (some_other_uri),
although unprefixed.

hi,

unprefixed attributes don't belong to any namespace !
so, qux doesn't belong to any namespace

the only way to bound an attribute to a namespace is to use a prefix

--
Cordialement,

///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------

 

[Ashmodai]

Philippe Poulard scribbled something along the lines of:

hi,

unprefixed attributes don't belong to any namespace !
so, qux doesn't belong to any namespace

the only way to bound an attribute to a namespace is to use a prefix

Yes and no. Unprefixed attributes on unprefixed elements which belong to
a namespace belong to the same namespace as their elements.

<foo xmlns="http://www.example.com" bar="qux"/>

The attribute bar belongs to the same namespace here as foo (in fact
XHTML works that way - otherwise all attributes in XHTML would belong to
no namespace which obviously is NOT the case).

That is why I'm unsure about the unprefixed attribute on a prefixed
element case.

In the following case:

<x:foo xmlns:x="http://www.example.com" bar="qux"/>

bar is unprefixed whereas its element is. That is where my problem comes
from. Most documents with default namespaces you find on the net look
like this:

<foo xmlns="http://www.example.net" xmlns:x="http://www.example.com">
<x:bar baz="qux"/>
</foo>

and assume baz belongs to the namespace of its element although it has
no prefix and thus either defaults back to the unprefixed namespace or
to "no namespace".

However, logically in the following case:

<foo xmlns="http://www.example.net" xmlns:x="http://www.example.com">
<x:bar>
<baz/>
</x:bar>
</foo>

baz is an unprefixed element and as namespaces are not inherited from
parent elements in the tree, baz belongs to the unprefixed namespace
"http://www.example.net", not to its parent's namespace
"http://www.example.com".
(for example, in an XML Schema with the xs: prefix for the schema
namespace, the contained elements will still be prefixed even though the
root is prefixed already. unprefixed names belong to the default
namespace (which may or may not be set) - this is because the prefix of
an element is a reference to a namespace and if it is unprefixed, it
belongs to whatever namespace has been defined for that).

With the original example:

<foo xmlns='someuri'>
<baz xmlns='some_other_uri'>
<frotz/>
</baz>
</foo>

the unprefixed namespace is overwritten at baz and thus frotz belongs to
'some_other_uri', not 'someuri'.
Same happens with:

<x:foo xmlns:x="someuri">
<x:baz xmlns:x="some_other_uri">
<x:frotz/>
</x:baz>
</x:foo>


frotz belongs to 'some_other_uri' here as well.
This is out of question.

 

[Ashmodai]

In retrospect, attributes of prefixed elements don't need to be prefixed
unless they belong to a different namespace than their element.

<x:foo bar="qux"/>
is as valid as
<x:foo x:bar="qux"/>

At least that is what the authors of the official schemas at W3C
apparently think.
Note that the only prefixed attributes most elements in official
documents have are xml:lang, xml:base, etc, which have the reserved
xmlrefix.

When dealing with XLinks and so, you have attributes of the
XLink-namespace which are being attached to elements of other
namespaces. That is the sole reason they need to be prefixed.


In the following:

<foo xmlns="http://www.example.net" xmlns:x="http://www.example.com">
<x:bar baz="qux"/>
</foo>

it is therefore wrong to assume baz defaults to the unprefixed namespace.


...

Another case of self-education by spontaneous enlightenment as it seems.

 

[Philippe Poulard]

Philippe Poulard scribbled something along the lines of:



Yes and no. Unprefixed attributes on unprefixed elements which belong to
a namespace belong to the same namespace as their elements.

mmmh, that's quite wrong

please have a look at the specification
http://www.w3.org/TR/1999/REC-xml-names-19990114/

in particular, chapter 5.3 will enlight you on attributes

<foo xmlns="http://www.example.com" bar="qux"/>

The attribute bar belongs to the same namespace here as foo (in fact
XHTML works that way - otherwise all attributes in XHTML would belong to
no namespace which obviously is NOT the case).

no, bar has no namespace

That is why I'm unsure about the unprefixed attribute on a prefixed
element case.

In the following case:

<x:foo xmlns:x="http://www.example.com" bar="qux"/>

bar has no namespace too

bar is unprefixed whereas its element is. That is where my problem comes
from. Most documents with default namespaces you find on the net look
like this:

<foo xmlns="http://www.example.net" xmlns:x="http://www.example.com">
<x:bar baz="qux"/>
</foo>

baz has no namespace

and assume baz belongs to the namespace of its element although it has
no prefix and thus either defaults back to the unprefixed namespace or
to "no namespace".

However, logically in the following case:

<foo xmlns="http://www.example.net" xmlns:x="http://www.example.com">
<x:bar>
<baz/>
</x:bar>
</foo>

baz is an unprefixed element and as namespaces are not inherited from
parent elements in the tree,

and yet they are

baz belongs to the unprefixed namespace

"http://www.example.net", not to its parent's namespace
"http://www.example.com".
right

(for example, in an XML Schema with the xs: prefix for the schema
namespace, the contained elements will still be prefixed even though the
root is prefixed already. unprefixed names belong to the default
namespace (which may or may not be set) - this is because the prefix of
an element is a reference to a namespace and if it is unprefixed, it
belongs to whatever namespace has been defined for that).

With the original example:

<foo xmlns='someuri'>
<baz xmlns='some_other_uri'>
<frotz/>
</baz>
</foo>

the unprefixed namespace is overwritten at baz and thus frotz belongs to
'some_other_uri', not 'someuri'.
right

Same happens with:

<x:foo xmlns:x="someuri">
<x:baz xmlns:x="some_other_uri">
<x:frotz/>
</x:baz>
</x:foo>

right


frotz belongs to 'some_other_uri' here as well.
This is out of question.

--
Cordialement,

///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------

 

[Philippe Poulard]

In retrospect, attributes of prefixed elements don't need to be prefixed
unless they belong to a different namespace than their element.
wrong


<x:foo bar="qux"/>
is as valid as
<x:foo x:bar="qux"/>

notice that validation is another question that is out of the scope of
our problem

i guess that you think that they are the same, whereas they are not;
what do you think about :

At least that is what the authors of the official schemas at W3C
apparently think.

they thought more certainly the same things that the authors of the
official namespace recommendation at w3c

Note that the only prefixed attributes most elements in official
documents have are xml:lang, xml:base, etc, which have the reserved
xmlrefix.

xml is a prefix automatically and systematically bound to
"http://www.w3.org/XML/1998/namespace"

however, it can't be override by the same or another declaration

that is like if any xml document were defined the following declaration
on its root element :
xmlns:xml="http://www.w3.org/XML/1998/namespace"

When dealing with XLinks and so, you have attributes of the
XLink-namespace which are being attached to elements of other
namespaces. That is the sole reason they need to be prefixed.

XLink defines a grammar that "works" only thanks to attributes

In the following:

<foo xmlns="http://www.example.net" xmlns:x="http://www.example.com">
<x:bar baz="qux"/>
</foo>

it is therefore wrong to assume baz defaults to the unprefixed namespace.

baz has no namespace

..

Another case of self-education by spontaneous enlightenment as it seems.

--
Cordialement,

///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------

 

[Richard Tobin]

unprefixed attributes don't belong to any namespace !
so, qux doesn't belong to any namespace

the only way to bound an attribute to a namespace is to use a prefix

[/QUOTE]

Yes and no. Unprefixed attributes on unprefixed elements which belong to
a namespace belong to the same namespace as their elements.

This is one of the most confusing issues about namespaces. The
original Namespaces 1.0 spec talked - in a non-normative appendix -
about per-element namespace partitions, which are effectively
sub-namespaces. Most later specifications - notably XPath/XSLT - did
not use this language: in fact, they rarely talked about names being
in namespaces at all; instead they talked about
namespace-name/local-name pairs (expanded names). In that
terminology, unprefixed attributes have a null namespace name, and it
is natural to say that they are in no namespace.

The key point about unprefixed attributes is that their interpretation
is controlled by the element they appear on. Prefixed attributes on
the other hand are intended to be "global": they mean the same
regardless of what element they appear on.

Unfortunately nothing guarantees (or even implies) that the global
attribute foo from http://example.org namespace means the same as the
unprefixed foo attribute on an element from the http://example.org
namespace.

The following example illustrates this:

<foo:elem xmlnsne="http://example.org" xmlns:two="http://example.org"
one:foo="abc" two:foo="xyz"/>

is illegal, because it has two attributes with local name "foo" and
namespace name "http://example.org", but

<foo:elem xmlnsne="http://example.org"
one:foo="abc" foo="xyz"/>

is legal: one:foo and foo do not have the same namespace name.

So to summarize, unprefixed attributes are in no namespace; their
namespace name is null, or has no value. Their interpretation is
determined by the element they appear on, and that interpretation may
be different for different elements from the same namespace.

-- Richard

 

[Ashmodai]

Philippe Poulard scribbled something along the lines of:

mmmh, that's quite wrong

please have a look at the specification
http://www.w3.org/TR/1999/REC-xml-names-19990114/

in particular, chapter 5.3 will enlight you on attributes

Hm, probably another case of effed up recs. Maybe we should get an
official say on this - if "the default namespace does not apply to
attribute names" as the rec says, the W3C really fucked up (sorry) big
time. Especially because they keep on violating this rule in every
single file they have online.

I think it's an error which slipped through. The CSS recommendations
also contain contradicting statements although they have reached
recommendation status with the flaws still present.
I will ask in the mailing list, it is likely they are able to solve that.

<snip/>

I'd say we should leave it at that. You are right with what the
namespace says, but I don't think that's the correct intended behavior,
especially as all schemas and XHTML files and so on the W3C ever
released violate this convention [1].

[1] EX: http://www.w3.org/MarkUp/Forms/2002/XForms-Schema.xsd

 

[Ashmodai]

Also see:
http://lists.w3.org/Archives/Public/xml-names-issues/1998OctDec/0013.html
http://lists.w3.org/Archives/Public/xml-names-issues/1998JulSep/0087.html

And more importantly:
http://www.w3.org/TR/1999/REC-xml-names-19990114/#ns-expnames
http://www.w3.org/TR/1999/REC-xml-names-19990114/#check-uniqattr

The local attributes automatically have the namespace of their
containing element (A.3 - especially note the lines 4 and 5 in the first
example and line 4 in the second one).

That explains why you are wrong:

baz has no namespace

<x:bar baz="qux"/> is expanded (per A.3) as follows:

<ExpEType type="bar" ns="http://www.example.com" />
<ExpAName name='qux' eltype="bar" elns="http://www.example.com" />


...

Hah! I win!

 

[Ashmodai]

Philippe Poulard scribbled something along the lines of:

notice that validation is another question that is out of the scope of
our problem

I wasn't talking about validation, I was talking about correctnes. Valid
may not have been the apropriate term, but I was not thinking of
validation in the terms of per-DTD validation, which I personally deem
inferior and deprecated when dealing with modern XML.

i guess that you think that they are the same, whereas they are not;
what do you think about :
<x:foo bar="qux" x:bar="qux"/>

As per [1] and [2] this is bad. Both attributes share the same namespace
(the first because it will be expanded as per [1] and the second because
it shares the prefix of its containing element and thus has the same
namespace as the first one).

Actually I'm not entirely sure. The recommendation seems to be as
contradicting as the CSS 2 spec when it comes to attributes.
Ah, well, it's not important whether the attribute really is in the
namespace as long as it is expanded properly. If that didn't work out
right, XMLNS had no chance of survival.

Also see my earlier reply <[email protected]>.

[1] http://www.w3.org/TR/1999/REC-xml-names-19990114/#check-uniqattr
[2] http://www.w3.org/TR/1999/REC-xml-names-19990114/#uniqAttrs

 

[Ashmodai]

I don't know why my mail program (no, it's not OE) thought I was
replying to YOUR post when I wasn't, but anyway.

Richard Tobin scribbled something along the lines of:

Yes and no. Unprefixed attributes on unprefixed elements which belong to
a namespace belong to the same namespace as their elements.

This is one of the most confusing issues about namespaces. The
original Namespaces 1.0 spec talked - in a non-normative appendix -
about per-element namespace partitions, which are effectively
sub-namespaces. Most later specifications - notably XPath/XSLT - did
not use this language: in fact, they rarely talked about names being
in namespaces at all; instead they talked about
namespace-name/local-name pairs (expanded names). In that
terminology, unprefixed attributes have a null namespace name, and it
is natural to say that they are in no namespace.
The key point about unprefixed attributes is that their interpretation
is controlled by the element they appear on. Prefixed attributes on
the other hand are intended to be "global": they mean the same
regardless of what element they appear on.[/QUOTE]

"the interpretation of unprefixed attributes is determined by the
element on which they appear." (Namespaces in XML 1.1)

Seems you're right.

The explanation is all but satisfying tho.

Unfortunately nothing guarantees (or even implies) that the global
attribute foo from http://example.org namespace means the same as the
unprefixed foo attribute on an element from the http://example.org
namespace.

I think the editors went kinda overboard here. The recommendation
creates more problems than it solves - or so it seems to me.

The following example illustrates this:

<foo:elem xmlnsne="http://example.org" xmlns:two="http://example.org"
one:foo="abc" two:foo="xyz"/>

is illegal, because it has two attributes with local name "foo" and
namespace name "http://example.org", but

<foo:elem xmlnsne="http://example.org"
one:foo="abc" foo="xyz"/>

is legal: one:foo and foo do not have the same namespace name.

So to summarize, unprefixed attributes are in no namespace; their
namespace name is null, or has no value. Their interpretation is
determined by the element they appear on, and that interpretation may
be different for different elements from the same namespace.

To summarize, unqualified (unprefixed) attributes are in no namespace,
but they are local to (i.e. belong to) their containing element, which
can have a namespace?

And I thought these guys had no humor.


...

I give in, your explanation apparently is the right one. It would have
saved a lot of time if someone had just given the actual reasons a bit
earlier rather than just talking binary.

Thanks for educating me. I'm not happier, I still think the namespaces
rec is faulty, but at least now I know for sure what it is trying to
express, although I do not agree with it.

Thanks, mate.

 

[Richard Tobin]

<x:bar baz="qux"/> is expanded (per A.3) as follows:

<ExpEType type="bar" ns="http://www.example.com" />
<ExpAName name='qux' eltype="bar" elns="http://www.example.com" />

(You mean name='baz', not name='qux'.)

(a) That appendix is non-normative.
(b) You will notice that baz does not have an "ns", which x:baz would.

In the terminology of the appendix, baz is in a namespace associated
with the element type "bar" in the the namespace "http://www.example.com".

In the terminology normally used today, baz is in no namespace. Its
namespace name is null, or has no value.

To say that it is in the namespace "http://www.example.com" is
misleading, since it is not the same attribute as x:baz, which is in
that namespace, and it does not have "http://www.example.com" as its
namespace name.

-- Richard

 

[Ashmodai]

Richard Tobin scribbled something along the lines of:

To say that it is in the namespace "http://www.example.com" is
misleading, since it is not the same attribute as x:baz, which is in
that namespace, and it does not have "http://www.example.com" as its
namespace name.

I've figured out where my misunderstanding came from, but anyway...
So you're saying baz has no namespace, but it does have a reference to a
namespace via its containing element?

My problem is that I'm used to treating references as replacements and
not as pointers. So to my original understanding the attribute had the
namespace of its containg element because it inherited it. I see now why
this is wrong, although I don't see why this decision (that namespace
defaulting doesn't work with attributes) has been made in the design.

 

[Patrick TJ McPhee]

% > i guess that you think that they are the same, whereas they are not;
% > what do you think about :
% > <x:foo bar="qux" x:bar="qux"/>
%
% As per [1] and [2] this is bad. Both attributes share the same namespace

Load a file into a namespace-aware parser and see what the parser
has to say about it. Try it out with an xslt processor. You'll find that
bar has no namespace, while x:bar has the same namespace as x:foo.

% (the first because it will be expanded as per [1] and the second because

Read [3], and notice where it says `Note that default namespaces do not
apply directly to attributes.' Now read [2] again. Notice the use of the
word prefix. Notice that the second example is essentially the same as
the one given above, and that `each of the following is legal, the
second because the default namespace does not apply to attribute names.'

[3] http://www.w3.org/TR/1999/REC-xml-names-19990114/#defaulting

 

[Patrick TJ McPhee]

% <snip/>
% > To say that it is in the namespace "http://www.example.com" is
% > misleading, since it is not the same attribute as x:baz, which is in
% > that namespace, and it does not have "http://www.example.com" as its
% > namespace name.
%
% I've figured out where my misunderstanding came from, but anyway...
% So you're saying baz has no namespace, but it does have a reference to a
% namespace via its containing element?

The attribute is interpreted in the context of its containing element,
so the namespace of the element has an effect on its interpretation.

The question you might be asking is why would it be useful for the
attribute to be in the namespace of its containing element?

 

[Ashmodai]

Patrick TJ McPhee scribbled something along the lines of:

The question you might be asking is why would it be useful for the
attribute to be in the namespace of its containing element?

The question I might be asking is why all the nitpicking of whether an
attribute is a namespace or only interpreted in the namespace of its
containing element if the only thing that apparently is attempted to be
made clear here is whether the attribute is local to the element or
global to the entire namespace.
I don't think it makes sense to define within the XML document whether
an element is global or local, it should be done in the defining
document (XML Schema, DTD, RELAX NG, whatever).
Why can't a local attribute, which belongs to an element which may have
a namespace, just inherit the namespace from its parent if it's
interpreted "in the context of its containing element" (i.e. also in the
namespace of its containg element) anyway?

Having a namespace or not should not be what makes an attribute local or
global.

If we went by that rule, we should drop namespace defaulting altogether
and declare unqualified elements as to be interpreted in the context of
their parent element. Tada, local elements.

I'm not critizing you, I'm critizing the rec.

 

[Patrick TJ McPhee]

% <snip/>
% > The question you might be asking is why would it be useful for the
% > attribute to be in the namespace of its containing element?
%
% The question I might be asking is why all the nitpicking of whether an
% attribute is a namespace or only interpreted in the namespace of its
% containing element if the only thing that apparently is attempted to be

Because it makes a difference at the processing level. If you process an
XML file, you take name spaces into account, and you want to process the
file correctly, then it matters how unprefixed attributes are handled.
The reason for `all the nitpicking' is that you repeatedly insisted that
your totally incorrect interpretation was correct. For instance, based on
your advice, it would be impossible to write a correct XSL transformation
involving attributes.

% Having a namespace or not should not be what makes an attribute local or
% global.

And it isn't. _Every_ attribute is intepreted in the context of the
containing element -- not of its namespace, but of the element itself.
Even if the attribute has a namespace, its meaning can be tied to the
element of which it's a part. As it happens, the interpretation of
certain elements is fairly uniform, and attributes with namespaces
lead the way, but whether an attribute is `local' or `global' depends
entirely on how you use it.

% If we went by that rule, we should drop namespace defaulting altogether
% and declare unqualified elements as to be interpreted in the context of
% their parent element. Tada, local elements.

From a processing perspective, you can do this. You'll have a problem
validating against a DTD if you want to include parts of a DTD with
name conflicts, and of course that's the sort of problem namespaces
were meant to resolve. You don't typically have naming conflicts
with attributes, so you might ask yourself why it would be useful
for the attribute to be in the namespace of its containing element.