What is a qualified name (Namespaces in XML) ?

[Ludovic Kuty]

Dear group readers,

Both "Namespaces in XML" recommendations (1.0 and 1.1) define a
qualified name with the following sentence :

"A qualified name is a name subject to namespace interpretation."

This is rather vague. To clarify things, I went checking the BNF
grammar of productions 7, 8 and 9, and saw :

[7] QName ::= PrefixedName | UnprefixedName
[8] PrefixedName ::= Prefix ':' LocalPart
[9] UnprefixedName ::= LocalPart

So at the syntactic level, a qualified name is prefixed or is not prefixed.

My question is : is a qualified name _always_ in a NS (prefixed means
there is an explicit NS binding and unprefixed means there is a default
NS declaration) or is a qualified name sometimes not in any NS i.e.
there is no default NS declaration and the name has no prefix ?

I ask this because I thought that a qualified name could be a name
outside any NS. And then I read in "Definitive XML Schema" 2nd edition
by Priscilla Walmsley that "Unqualified names, on the other hand, are
names that are not in any namespace" (page 40). Things are clear from
her point of view but I found it not so clear in the recommendation,
that's why I am asking this here. Of course, I then told myself that
using the term "qualified" would be weird if the name was not in any NS.

So the next question is : is there a place in the recommendation where
this is answered clearly ?

TIA

Ludovic Kuty

 

[Alain Ketterlin]

Both "Namespaces in XML" recommendations (1.0 and 1.1) define a
qualified name with the following sentence :

"A qualified name is a name subject to namespace interpretation."

This is rather vague. To clarify things, I went checking the BNF
grammar of productions 7, 8 and 9, and saw :

[7] QName ::= PrefixedName | UnprefixedName
[8] PrefixedName ::= Prefix ':' LocalPart
[9] UnprefixedName ::= LocalPart

So at the syntactic level, a qualified name is prefixed or is not prefixed.

Yes. Qualified means "the name has an associated namespace".

My question is : is a qualified name _always_ in a NS (prefixed means
there is an explicit NS binding and unprefixed means there is a
default NS declaration) or is a qualified name sometimes not in any NS
i.e. there is no default NS declaration and the name has no prefix ?

Namespace in XML 1.0, section 6.2 :

"If there is a default namespace declaration in scope, the expanded name
corresponding to an unprefixed element name has the URI of the default
namespace as its namespace name. If there is no default namespace
declaration in scope, the namespace name has no value."

We're left to guess what "... has no value" means. Section 2.1 says:

"For a name N that is not in a namespace, the namespace name has no
value."

which I take as an implication, but should be an equivalence: if the
namespace name has no value, does it mean that the name is not in any
namespace? I guess yes, but that's a guess.

I ask this because I thought that a qualified name could be a name
outside any NS. And then I read in "Definitive XML Schema" 2nd edition
by Priscilla Walmsley that "Unqualified names, on the other hand, are
names that are not in any namespace" (page 40).

Right. Unqualified, not unprefixed.

Things are clear from her point of view but I found it not so clear in
the recommendation, that's why I am asking this here. Of course, I
then told myself that using the term "qualified" would be weird if the
name was not in any NS.

So the next question is : is there a place in the recommendation where
this is answered clearly ?

"Clearly" is subjective I find it confusing too. Perhaps I've missed
something, because this point is fundamental to accomodate documents
that use no namespace at all.

-- Alain.

 

[Joe Kesselman]

"For a name N that is not in a namespace, the namespace name has no

value."

The easiest way to think of the "no namespace" case is that it is a
namespace whose URI is the special value "" or empty or null (depending
on how the tool or API you're using presents this case). Namespace-aware
code can look for and process this "no-namespace namespace" in much the
same way it looks for and processes other namespaces.

The term "qualified name" was really introduced as an opportunity to
make the grammar of XML Namespaces explicit at the BNF level without
having to go back and modify the basic XML Recommendation. There isn't
intended to be a concept of "unqualified names" -- all XML names are
QNames unless you're using archaic, pre-namespace XML tools. (Which you
really, REALLY, should no longer be doing. Trying to mix namespace-aware
and non-namespace-aware processing is a great way to get into trouble.)

As far as "clearly" goes -- W3C recommendations are deliberately written
to be "prescriptive, not descriptive". They're clear for an expert who
has to implement these specs; it is assumed that non-experts will
generally be working from tutorial material based on the recommendations
rather than trying to read the REC itself. (This is a bit of a sore
point for me, having been told "no" when I wanted to include more
examples in a section of the DOM REC I was editing.)

Generally, unless you're fluent in spec-ese, you're probably better off
working with resources like IBM's DeveloperWorks website, and going
direct to the Recommendations only if what those more-readable docs are
telling you doesn't seem to make sense and you need to sanity-check it.

--
Joe Kesselman,
http://www.love-song-productions.com/people/keshlam/index.html

{} ASCII Ribbon Campaign | "may'ron DaroQbe'chugh vaj bIrIQbej" --
/\ Stamp out HTML mail! | "Put down the squeezebox & nobody gets hurt."

 

[gordon89586]

Dear group readers,



Both "Namespaces in XML" recommendations (1.0 and 1.1) define a

qualified name with the following sentence :



"A qualified name is a name subject to namespace interpretation."



This is rather vague. To clarify things, I went checking the BNF

grammar of productions 7, 8 and 9, and saw :



[7] QName ::= PrefixedName | UnprefixedName

[8] PrefixedName ::= Prefix ':' LocalPart

[9] UnprefixedName ::= LocalPart



So at the syntactic level, a qualified name is prefixed or is not prefixed.



My question is : is a qualified name _always_ in a NS (prefixed means

there is an explicit NS binding and unprefixed means there is a default

NS declaration) or is a qualified name sometimes not in any NS i.e.

there is no default NS declaration and the name has no prefix ?



I ask this because I thought that a qualified name could be a name

outside any NS. And then I read in "Definitive XML Schema" 2nd edition

by Priscilla Walmsley that "Unqualified names, on the other hand, are

names that are not in any namespace" (page 40). Things are clear from

her point of view but I found it not so clear in the recommendation,

that's why I am asking this here. Of course, I then told myself that

using the term "qualified" would be weird if the name was not in any NS.



So the next question is : is there a place in the recommendation where

this is answered clearly ?



TIA



Ludovic Kuty

this site has a few good tutorials on the subject including a good xml overview, http://www.liquid-technologies.com/xml.aspx

 

[Ludovic Kuty]

The easiest way to think of the "no namespace" case is that it is a
namespace whose URI is the special value "" or empty or null (depending
on how the tool or API you're using presents this case).
Namespace-aware code can look for and process this "no-namespace
namespace" in much the same way it looks for and processes other
namespaces.

The term "qualified name" was really introduced as an opportunity to
make the grammar of XML Namespaces explicit at the BNF level without
having to go back and modify the basic XML Recommendation. There isn't
intended to be a concept of "unqualified names" -- all XML names are
QNames unless you're using archaic, pre-namespace XML tools. (Which you
really, REALLY, should no longer be doing. Trying to mix
namespace-aware and non-namespace-aware processing is a great way to
get into trouble.)

As far as "clearly" goes -- W3C recommendations are deliberately
written to be "prescriptive, not descriptive". They're clear for an
expert who has to implement these specs; it is assumed that non-experts
will generally be working from tutorial material based on the
recommendations rather than trying to read the REC itself. (This is a
bit of a sore point for me, having been told "no" when I wanted to
include more examples in a section of the DOM REC I was editing.)

Generally, unless you're fluent in spec-ese, you're probably better off
working with resources like IBM's DeveloperWorks website, and going
direct to the Recommendations only if what those more-readable docs are
telling you doesn't seem to make sense and you need to sanity-check it.

Thanks Joe for the clarification. It was quite uncomfortable with the
text you've written but it looks coherent to me. Also the following
sentence taken from the recommendation let me think you're right.

"In documents conforming to this specification, element and attribute
names appear as qualified names."

Thus any "recent" (or "modern") XML document wich should comply with
both recommendations XML and Namespaces in XML will only contain
qualified names and nothing else.

I am less at ease with using a trick like the no-NS whose URI is "" or
null. I think I will also choose the way of being open minded and
accept things like "unqualified names" when I know the precise meaning
of the term that is used. Of course the use of such a term will modify
the existing meaning of "qualified name". But well, if it can help me
to read and understand books about XML, that's ok for me.

I like to know things precisely but your paragraph which begins with
"As far as "clearly" goes" invites me to put things in perspective and
focus more on the how-to-do-things that on the what-things-are-made-of.
As a teacher, I also want to be clear on the topic but I don't want to
lose my students following that path. Lots of examples should clarify
the matter for them.

 

[Joe Kesselman]

I like to know things precisely but your paragraph which begins with "As
far as "clearly" goes" invites me to put things in perspective and focus
more on the how-to-do-things that on the what-things-are-made-of. As a
teacher, I also want to be clear on the topic but I don't want to lose
my students following that path. Lots of examples should clarify the
matter for them.

Sounds good. Formalisms are great for the times when rigor is required
(eg when you're implementing what's being described and need to be
Absolutely Sure yours behaves like everyone else's), but practical
examples and general intuitive definitions are fine for everyday use.

For your students, I'd avoid the term "qualified name" entirely. They're
just names. Some names have prefixes, which associate them with specific
namespaces. (You can think of the prefixed name as shorthand for a
longer name that includes the namespace URI, though that expanded syntax
was rarely used except when discussing the behavior of code -- which may
be a pity.) Other names don't have prefixes, and either the name stands
by itself or was associated with the namespace using the
default-namespace (xmlns=) mechanism, which is "a shorthand for the
shorthand".

Important point which folks tend to miss: The default namespace
definition DOES NOT AFFECT ATTRIBUTES. If the aren't prefixed, they
aren't associated with any namespace, period. That's often entirely
acceptable since the namespaced element they appear in provides
context... but it's something to be aware of when working with these
documents.

Another important point: If you're using the DOM, the old "level 1"
non-namespace-aware methods for creating elements and attributes are NOT
compatible with namespace aware "level 2" processing. The former should
be considered deprecated except when interfacing with ancient
level-1-only DOM applications. See the W3C's DOM FAQ for a few more
words on that topic. (I fought hard to find a way to avoid that
compatibility break, and failing that to officially deprecate the old
calls... but the W3C didn't have a deprecation mechanism and other folks
weren't comfortable trying to write the deprecation more clearly into
the spec since Level 1 is officially still supported.)


There are ways this all could be made clearer if we had designed XML
completely before releasing it. But then it wouldn't have gotten the
early adopters and the traction needed to establish itself in the
industry. Maybe someday there'll be an XML 2.0 where we can rewrite
everything into coherent form -- define the infoset first with
namespaces and schemas and such fully incorporated into that document,
then define the syntax and APIs and tools on top of that. For now, we
have to live with afterthoughts and looking at multiple documents to
resolve what should be simple questions.

One more afterthought: If you're interested in why XML is as it is, I
*highly* recommend the Annotated XML Recommendation website. It
clarifies what the authors of XML 1.0.0 intended some of the more
obscure phrases to mean, why they made the decisions they did, and
generally puts the whole thing into much clearer context. It's a pity
nobody had the time or energy to do that to later revisions and/or to
the other standards.


--
Joe Kesselman,
http://www.love-song-productions.com/people/keshlam/index.html

{} ASCII Ribbon Campaign | "may'ron DaroQbe'chugh vaj bIrIQbej" --
/\ Stamp out HTML mail! | "Put down the squeezebox & nobody gets hurt."

 

[Joe Kesselman]

(The only time I'd mention qualified names is when dealing with a tool
or API which uses that term, and then explain that this is a historical
artifact intended to remind folks that the actual semantic "name" does
not include the prefix -- which is just a convenience shorthand -- but
does include the namespace.)

--
Joe Kesselman,
http://www.love-song-productions.com/people/keshlam/index.html

{} ASCII Ribbon Campaign | "may'ron DaroQbe'chugh vaj bIrIQbej" --
/\ Stamp out HTML mail! | "Put down the squeezebox & nobody gets hurt."

 

[cmsmcq]

Namespace in XML 1.0, section 6.2 :

"If there is a default namespace declaration in scope, the expanded name
corresponding to an unprefixed element name has the URI of the default
namespace as its namespace name. If there is no default namespace
declaration in scope, the namespace name has no value."


We're left to guess what "... has no value" means. Section 2.1 says:

"For a name N that is not in a namespace, the namespace name has no
value."

which I take as an implication, but should be an equivalence: if the
namespace name has no value, does it mean that the name is not in any
namespace? I guess yes, but that's a guess.

No, it doesn't. That is a not uncommon way of thinking and
speaking; I've even heard editors of the Namespaces spec say
things like it in public, but the text of the spec is carefully
written NOT to license that inference. If a name is unqualified
(= if the namespace name part of an expanded name has no
value), it might or might not be 'the same' (for some notion of
sameness) as a name in a namespace.

Most specifications and most software treat unqualified names
as if the null namespace value were just another namespace.
That is, they treat an unqualified 'body' element as different
from a 'body' element in the XHTML namespace. The passage
you quote is an implication and not an equivalence, however,
precisely in order to make it possible to know by some other
means that a given unqualified name is actually to be treated
as being in a namespace.