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

--
NOTE: In my address everything before the period is backwards.

[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]

In article <c5**********@reader1.panix.com>, kj <so***@987jk.com> wrote:

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.)
It belongs to the default namespace, which is "no namespace". <baz/> has
no defined namespace here.
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,
has been redefined in <baz/>, of which <frotz/> is a child element.
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.

--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[Philippe Poulard]

Ashmodai wrote:

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.)

It belongs to the default namespace, which is "no namespace". <baz/> has
no defined namespace here.

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,
has been redefined in <baz/>, of which <frotz/> is a child element.

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.

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.

--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[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
xml:-prefix.

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.

--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[Philippe Poulard]

Ashmodai wrote:

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.

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]

Ashmodai wrote:

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 :
<x:foo bar="qux" x:bar="qux"/>

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
xml:-prefix.
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]

In article <c5*************@news.t-online.com>,
Ashmodai <as******@mushroom-cloud.com> wrote:

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.

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 xmlns:one="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 xmlns:one="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:

Ashmodai wrote:

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.

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
--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[Ashmodai]

Also see:
http://lists.w3.org/Archives/Public/...tDec/0013.html
http://lists.w3.org/Archives/Public/...lSep/0087.html

And more importantly:
http://www.w3.org/TR/1999/REC-xml-na...4/#ns-expnames
http://www.w3.org/TR/1999/REC-xml-na...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:

Ashmodai wrote:

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

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!

--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[Ashmodai]

Philippe Poulard scribbled something along the lines of:
<snip/>

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 <c5*************@news.t-online.com>.

[1] http://www.w3.org/TR/1999/REC-xml-na...check-uniqattr
[2] http://www.w3.org/TR/1999/REC-xml-na...114/#uniqAttrs
--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[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:

In article <c5*************@news.t-online.com>,
Ashmodai <as******@mushroom-cloud.com> wrote:

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.

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.

"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 xmlns:one="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 xmlns:one="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.
--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[Richard Tobin]

In article <c5*************@news.t-online.com>,
Ashmodai <as******@mushroom-cloud.com> wrote:

<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:
<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?

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.

--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[Patrick TJ McPhee]

In article <c5*************@news.t-online.com>,
Ashmodai <as******@mushroom-cloud.com> wrote:

% > 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-na...14/#defaulting
--

Patrick TJ McPhee
East York Canada
pt**@interlog.com

[Patrick TJ McPhee]

In article <c5*************@news.t-online.com>,
Ashmodai <as******@mushroom-cloud.com> wrote:
% Richard Tobin scribbled something along the lines of:
% <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?

--

Patrick TJ McPhee
East York Canada
pt**@interlog.com

[Ashmodai]

Patrick TJ McPhee scribbled something along the lines of:
<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
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.
--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[Patrick TJ McPhee]

In article <c5*************@news.t-online.com>,
Ashmodai <as******@mushroom-cloud.com> wrote:
% Patrick TJ McPhee scribbled something along the lines of:
% <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.

--

Patrick TJ McPhee
East York Canada
pt**@interlog.com

[Ashmodai]

Patrick TJ McPhee scribbled something along the lines of:

In article <c5*************@news.t-online.com>,
Ashmodai <as******@mushroom-cloud.com> wrote:
% Patrick TJ McPhee scribbled something along the lines of:
% <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.
I wasn't talking about the nitpicking in this discussion, which does not
exist (stating the truth can hardly be called nitpicking).

Let me rephrase:
"The question I might be asking is, why does it matter whether an
attribute [..]?"

You answered that now.

I did not intend to criticize that you guys were defending a fact, I
only said it'd have shortened it a little if you had fully explained why
my perecption was wrong and what was right from the start. Also it
wouldn't have made me end up looking like a total standards-ignorant retard.
% 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.
Give me a break, you're saying the difference between a prefixed and an
unprefixed attribute is that the prefixed one has a namespace and the
unprefixed one does not, but both get interpreted in the context of the
element? So how does <x:foo x:bar="1" bar="2"/> have any reason to exist?
What is the point of giving a local attribute a prefix? I'm not
questioning it, I just don't understand.
% 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.

So you too think <x:foo x:bar="qux"/> with bar being a local attribute
is a waste of markup?

OT#1:
What's the point of DTDs when working with namespaces? Doesn't that
pretty much defeat the purpose? I mean, other ways to reference entity
lists could be worked out and maybe some kind of schema catalog as well.
Won't schemas be used in favor of DTDs?

OT#2:
Isn't using French accents as quotation marks typographically incorrect
-- or have I totally misread something?
Imagine someone was reading Usenet messages with a TTS converter -- I
wonder how that would sound.
--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[J Krugman]

In <c5**********@news.eusc.inter.net> pt**@interlog.com (Patrick TJ McPhee) writes:

You don't typically have naming conflicts
with attributes...

Why is that?

Are namespaces for attributes *ever* useful?

jill
--
To s&e^n]d me m~a}i]l r%e*m?o\v[e bit from my a|d)d:r{e:s]s.

[Richard Tobin]

In article <c5**********@news.eusc.inter.net>,
Patrick TJ McPhee <pt**@interlog.com> wrote:

And it isn't. _Every_ attribute is intepreted in the context of the
containing element -- not of its namespace, but of the element itself.
You might say that every attribute is interpreted by whatever
application you apply to the document, and it is possible for an
application to interpret an attribute without consideration of the
element.

For example, some kind of browser might look for xlink:type
attributes, and allow you to follow the corresponding xlink:href
attribute, without even determining the element name.
% 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.

And XML Schemas provide support for it: unless you use
elementForm[Default]=qualified, local element declarations validate
elements in no namespace.

-- Richard

[J Krugman]

In <c5**********@reader2.panix.com> J Krugman <jk******@yahbitoo.com> writes:

In <c5**********@news.eusc.inter.net> pt**@interlog.com (Patrick TJ McPhee) writes:

You don't typically have naming conflicts
with attributes...

Why is that? Are namespaces for attributes *ever* useful?

Actually, I found a partial answer to my own question:

...the purpose of XML namespaces is to uniquely identify element
and attribute names. Unprefixed attribute names can be uniquely
identified based on the element type to which they belong, so
there is no need identify them further by including them in an
XML namespace. In fact, the only reason for allowing attribute
names to be prefixed is so that attributes defined in one XML
language can be used in another XML language.

(from http://www.rpbourret.com/xml/NamespacesFAQ.htm#q5_3)

I'm very inexperienced with XML; I can't think of a realistic
scenario in which one would want to use an attribute "defined in
one XML language" in "another XML language". Can someone point me
to examples of this?

Thanks!

jill

--
To s&e^n]d me m~a}i]l r%e*m?o\v[e bit from my a|d)d:r{e:s]s.

[Patrick TJ McPhee]

In article <c5**********@reader2.panix.com>,
J Krugman <jk******@yahbitoo.com> wrote:

% I'm very inexperienced with XML; I can't think of a realistic
% scenario in which one would want to use an attribute "defined in
% one XML language" in "another XML language". Can someone point me
% to examples of this?

I was engaging in a bit of hyperbole a few messages ago, but in general
you do it because you want to define some sort of processing which
could be applied to a wide array of elements. An example from the standard
is xml:lang, which can be used to define the language of the content of
any element. In another message, Tobin gives xlink as an example. You
can create an XML document which acts as its own XSLT style sheet by
defining an xsl:version attribute, where xsl maps to the XSLT namespace URI.

--

Patrick TJ McPhee
East York Canada
pt**@interlog.com

[Patrick TJ McPhee]

In article <c5*************@news.t-online.com>,
Ashmodai <as******@mushroom-cloud.com> wrote:
% Patrick TJ McPhee scribbled something along the lines of:

% > And it isn't. _Every_ attribute is intepreted in the context of the
% > containing element -- not of its namespace, but of the element itself.

[...]

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

% Give me a break, you're saying the difference between a prefixed and an
% unprefixed attribute is that the prefixed one has a namespace and the
% unprefixed one does not, but both get interpreted in the context of the
% element?

What I'm really saying is that XML defines syntax, not processing. You say
that having a name space shouldn't be what makes an attribute global, and
I say that it doesn't -- the definition of XML has nothing to say on the
subject. You can process the data however you like without violating the
spec. Do whatever the hell you want. What XML says is that in this:

% So how does <x:foo x:bar="1" bar="2"/> have any reason to exist?

x:bar has a name space (presumably), while bar doesn't. Whether it has
any reason to exist depends entirely on what you're doing. I would never
have that, but that doesn't mean nobody would.

% What's the point of DTDs when working with namespaces?

They serve the same role as they do the rest of the time. The key to
having it work is to define the name space prefix as an entity, and
put all the definitions for each name space in its own file
<!-- x.dtd -->
<!ELEMENT %xpx;:foo EMPTY>
<!ATTRIBUTE %xpx;:foo %xpx;:bar CDATA #IMPLIED
bar CDATA #IMPLIED>

<!-- y.dtd -->
<!ENTITY % xpx "x">
<!ENTITY % x SYSTEM "x.dtd">
%x;
<!ELEMENT y (%xpx;:foo+)>
<!ATTRIBUTE y xmlns:%xpx; FIXED "http://www.x.org/xns">

% Isn't using French accents as quotation marks typographically incorrect
% -- or have I totally misread something?

There is no typographically correct way to specify quotation marks in
ascii. One lives within one's limitations.
--

Patrick TJ McPhee
East York Canada
pt**@interlog.com