Whose attributes are they anyway?

[Soren Kuula]

Hi,

I just can't find namespaces of attributes stated clearly enough in the
XML namespace spec.
But .. I hear rumors that attributes, unless qualified otherwise,
default to the namespace of the owner element.
Is that right ?

Like:

<?xml version='1.0'?>

<!-- I would think that the "odor" attribute below should belong to the
"smelly->http://www.stench.com"
name space, as its owner element is in that? The irrelevantdor
attribute, of course, is in
the irrelevant->http://sweetaroma.org namespace ... right? -->

<smelly:skunk
xmlns:smelly="http://www.stench.com"
xmlns:irrelevant="http://sweetaroma.org"
xmlns="dongfang.dk"
odor="a"
irrelevantdor="b">

<!-- And I would think that these two elements are semantically
indistinguishable
- - although one is 'lexically' a bit more explicit about the namespace
of its
non-"irrelevant"-NS odor attribute than the other .. right? -->

<smelly:inner odor="1" irrelevantdor="2"/>
<smelly:inner smellydor="1" irrelevantdor="2"/>

<!-- this would be two attributes w same name in same name space and w
same owner element .. an error, right? -->
<smelly:inner smellydor="1" odor="2"/>
</smelly:skunk>

TNX for any reply

Soren (who actually needs to decorate element with attributes in a
different NS, without risk o' clashes)

 

[Soren Kuula]

What particularly puzzles (annoys) me is that dom4j, in this program:

import java.util.Iterator;
import java.util.List;

import org.dom4j.Attribute;
import org.dom4j.Document;
import org.dom4j.Element;
import org.dom4j.io.SAXReader;

/**
* @author dongfang
*/
public class AnnoyingDom4jAttributes {
public static void main (String[] args) throws Exception {
String filename =
"experimental-data/AnnoyingAttributes.xml";///args[0];
SAXReader builder = new SAXReader();

//builder.setFeature("http://xml.org/sax/features/namespaces",
true);

//builder.setFeature("http://xml.org/sax/features/namespace-prefixes",
false);

Document doc = builder.read(filename);

Element root = doc.getRootElement();

verbose(root);

for (Iterator children = root.elementIterator();
children.hasNext() {
verbose((Element)children.next());
}
}

private static void verbose(Element e) {
System.out.println("Naive name: " + e.getName());
System.out.println("qual name: " + e.getQualifiedName());
System.out.println("namespace: " + e.getNamespace());
List attrs = e.attributes();
for (int i=0; i<attrs.size(); i++) {
System.out.println("Att #" + i + ":");
Attribute a = (Attribute)attrs.get(i);
System.out.println(" Naive name: " + a.getName());
System.out.println(" qual name: " + a.getQualifiedName());
System.out.println(" namespace: " + a.getNamespace());
System.out.println(" value: " + a.getValue());
System.out.println("<<owner-element>>.getAttribute("+
a.getName() + ")"+" == this: " + (e.attribute(a.getName())==a));
System.out.println("<<owner-element>>.getAttribute("+
a.getQName() +")"+" == this: " + (e.attribute(a.getQName())==a));
}
System.out.println();
}
}


says about this element:

<smelly:inner odor="1" irrelevantdor="2"/>

:
Naive name: inner
qual name: smelly:inner
namespace: org.dom4j.Namespace@3d51bec5 [Namespace: prefix smelly mapped
to URI "http://www.stench.com"]
Att #0:
Naive name: odor
qual name: odor
namespace: org.dom4j.Namespace@babe [Namespace: prefix mapped to URI ""]
......

-- the odor attribute is not mapped to the name space of the owner
element, not to the default namespace (dongfang.dk) either, but to the
empty string NS. ARGH.

This one

<smelly:inner smellydor="1" irrelevantdor="2"/>

Naive name: inner
qual name: smelly:inner
namespace: org.dom4j.Namespace@3d51bec5 [Namespace: prefix smelly mapped
to URI "http://www.stench.com"]
Att #0:
Naive name: odor
qual name: smellydor
namespace: org.dom4j.Namespace@3d51bec5 [Namespace: prefix smelly
mapped to URI "http://www.stench.com"]

maps the way I like it.

I just wonder, is that a bug I have spotted there, or am I the bug?

JDOM does the same.

Soren

 

[Martin Honnen]

Soren Kuula wrote:

says about this element:

<smelly:inner odor="1" irrelevantdor="2"/>

:
Naive name: inner
qual name: smelly:inner
namespace: org.dom4j.Namespace@3d51bec5 [Namespace: prefix smelly mapped
to URI "http://www.stench.com"]
Att #0:
Naive name: odor
qual name: odor
namespace: org.dom4j.Namespace@babe [Namespace: prefix mapped to URI ""]
.....

-- the odor attribute is not mapped to the name space of the owner
element, not to the default namespace (dongfang.dk) either, but to the
empty string NS. ARGH.

I don't know JDOM or dom4j in detail but an attribute with a name
without a prefix is indeed in no namespace, check the specification
about namespaces in XML.

 

[Patrick TJ McPhee]

% I just can't find namespaces of attributes stated clearly enough in the
% XML namespace spec.
% But .. I hear rumors that attributes, unless qualified otherwise,
% default to the namespace of the owner element.
% Is that right ?

No. Unqualified attributes have no namespace. What the spec says is that
the default name space does not apply to attributes.

 

[Soren Kuula]

% I just can't find namespaces of attributes stated clearly enough in the
% XML namespace spec.
% But .. I hear rumors that attributes, unless qualified otherwise,
% default to the namespace of the owner element.
% Is that right ?

No. Unqualified attributes have no namespace. What the spec says is that
the default name space does not apply to attributes.

Hi, thank you both of you.

ARGH!
That means, I guess, that most application writers (particularly XSL)
just assume that unqualified attributes are theirs? I have not heard
about many XML authors who bothered to qualify their attributes.

What's the right thing to expect then? I'm writing stuff that processes
XSL stylesheets, it should work with all the ones that have worked in
XSL processors. Right now, I assume that an attribut is XSL if it is in
the XSL namespace, or in the emptd named namespace.

Talking of XSL: Is there a schema for that somewhere? I have seen the
quasi-DTD in the spec -- is there anything around more precise than that?

Finally, can anyone see a good reason for the XML namespace attribute
namespacing design (no qual-->empty namespace) -- why not no
qual-->owner element's namespace? It would be nicer -- in my opinion.

Soren

 

[David Carlisle]

Hi, thank you both of you.

ARGH!
That means, I guess, that most application writers (particularly XSL)
just assume that unqualified attributes are theirs?

In the case of xsl it's fully specified, so their is no need to assume
anything:
if the element is in the xsl namespace then any unnamespaced attributes
must be as specified in the xslt spec, any other unnamespaced attribute
is a syntax attribute. Any attribute in anamespace (other than xslt
namespace) is allowed in xslt and ignored by defaulut, but may be used
by an extension or documentation system.

conversely if the element is not in the xsl namespace then the xsl spec
says nothing about any attributes (if the element is a literal result
element such attributes are just copied to the result) but elements in
the xsl namespace are interpreted by the xsl processor and not copied to
the result.


so for example you put version="..." on xsl:stylesheet
but xsl:version on a top levelelement that is not in the xsl namespace
similarly you use exclude-result-prefixes on an xsl element but
xsl:exclude-result-prefixes on a non-xsl element.

I have not heard
about many XML authors who bothered to qualify their attributes.

mainly used by attributes that have the same meaning whatever namespace
of the element they are used for.
xml:base xsl:version xlink:href etc

What's the right thing to expect then? I'm writing stuff that processes
XSL stylesheets, it should work with all the ones that have worked in
XSL processors. Right now, I assume that an attribut is XSL if it is in
the XSL namespace, or in the emptd named namespace.

see above.

Talking of XSL: Is there a schema for that somewhere? I have seen the
quasi-DTD in the spec -- is there anything around more precise than that?

There's one for XSLT2 likned from the draft.

Finally, can anyone see a good reason for the XML namespace attribute
namespacing design (no qual-->empty namespace) -- why not no
qual-->owner element's namespace? It would be nicer -- in my opinion.

That rule would probably lead to more complicated rules making sure that
<a:x a:y="xx" and y="zz"/>
was (or wasn't) well defined. Presumably with your suggested rule this
would be an error as both attributes would be y in the namespace
associated with a:? It doesn't seem any more useful than the current
rule, really. Any rule is fairly arbitary.

Soren

David

 

[Richard Tobin]

That means, I guess, that most application writers (particularly XSL)
just assume that unqualified attributes are theirs? I have not heard
about many XML authors who bothered to qualify their attributes.

The way to look at it is that unprefixed attributes "belong to" the
element they're on. The only point to prefixing attributes is to
allow them to be used on elements from other namespaces. That's why
the attributes on XSL or XML Schema elements are unprefixed, while the
attributes defined by those standards that are used on your own
attributes (xsl:version, xsi:type etc) are prefixed.

Since the namespace spec was first drafted, there's been a drift in
terminology from considering things to be "in" namespaces to
considering them just as having qualified names with a namespace and
local part. If you wish, you can consider unprefixed attributes to be
conceptually in the namespace of their element (or as an appendix to
Namespaces 1.0 put it, in one of the "per-element partitions" of that
namespace), but specs and APIs generally talk in terms of qualified
names, and the qualified name of an unprefixed attribute has a null
namespace name.

Finally, can anyone see a good reason for the XML namespace attribute
namespacing design (no qual-->empty namespace) -- why not no
qual-->owner element's namespace? It would be nicer -- in my opinion.

I think one reason is that people didn't want to suggest that there
can only be one foo attribute in a given namespace. The foo
attributes of different elements in the namespace are different
attributes. Hence the "per-element partitions". I think this was a
mistake, and what you suggest would have saved a lot of confusion, but
it's too late now.

-- Richard

 

[Soren Kuula]

Hi, David, thanks for the response,

if the element is in the xsl namespace then any unnamespaced attributes
must be as specified in the xslt spec, any other unnamespaced attribute
is a syntax attribute. Any attribute in anamespace (other than xslt
namespace) is allowed in xslt and ignored by defaulut, but may be used
by an extension or documentation system.

I read it that these are equivalent in XSL, then:
<xsl:template xsl:match="...">...</xsl:template>

<xsl:template match="...">...</xsl:template>

For completeness, I will have to check both versions when looking for
the "match" attribute (and, presumable complain if both are present?).
Oh well, could have been worse

That rule would probably lead to more complicated rules making sure that
<a:x a:y="xx" and y="zz"/>
was (or wasn't) well defined. Presumably with your suggested rule this
would be an error as both attributes would be y in the namespace
associated with a:?

Yes

It doesn't seem any more useful than the current

rule, really. Any rule is fairly arbitary.

It would have made my check easier

BTW, I failed in making a purely imaginary example document.
http://www.stench.com has a target, would you imagine

Soren

 

[Richard Tobin]

I read it that these are equivalent in XSL, then:
<xsl:template xsl:match="...">...</xsl:template>

<xsl:template match="...">...</xsl:template>

No, the first is not allowed.

-- Richard

 

[David Carlisle]

I read it that these are equivalent in XSL, then:
<xsl:template xsl:match="...">...</xsl:template>


No, that is a syntax error. There is no xsl:match attribute in xsl.


David