Help! Namespace muddle

[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

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.

 

[J Krugman]

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

Why is that?

Are namespaces for attributes *ever* useful?

jill

 

[Richard Tobin]

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]

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

 

[Patrick TJ McPhee]

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

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