Another errata?

[Mark Birbeck]

There seems to be a lot of confusion here. A few interesting points have
been made, but I think the defence of the namespaces spec has not been
made strongly enough.

To recap: some people are querying as to why the namespaces spec does
not allow attributes that do not have a namespace specified to belong to
a default namespace. Elements with no namespace can belong to a default
one, they argue, so why can't attributes? Others in the discussion have
said, well, even if we accept this, why doesn't the attribute at least
belong to the same namespace as its element?

There are two confusions here:
- the first relates to default namespaces, and why their application to
attributes would be a problem, not a help
- the second relates to a misunderstanding as to what role namespaces
play anyway

Let's look at the default namespace question first. As Ronald said on
this thread - quoting from the namespaces spec - default namespaces do
NOT apply to attributes (or not *directly* anyway). To see why this is
necessary, imagine for a moment that they did. What would the following
document give us (picking up on an example from the namespaces spec)?:

    <xml xmlns='http://www.w3.org/TR/REC-html40'
xmlns:bk='urn:loc.gov:books'>
        <bk:book isbn="1568491379">
            <bk:title>Cheaper by the Dozen</bk:title>
        </bk:book>
    </xml>

In this document 'isbn' would be part of the HTML 4.0 namespace - not
what is intended at all! Now, everyone out there that's moaning - do you
really want to have to prefix every attribute with the namespace of its
element, to ensure it is not confused with a default namespace?

OK then, some have argued, at least shouldn't 'isbn' automatically be
part of the 'bk' namespace? Still no, I'm afraid. Every member of a
namespace is meant to be unique. If we do this 'auto-joining' we cannot
guarantee uniqueness. Let's extend the above example (having now
hopefully accepted that 'isbn' is *not* part of HTML 4.0) to include
another object which is probably not part of the 'urn:loc.gov:books'
namespace, but bear with me:

    <xml xmlns='http://www.w3.org/TR/REC-html40'
xmlns:bk='urn:loc.gov:books'>
        <bk:book isbn="1568491379">
            <bk:title>Cheaper by the Dozen</bk:title>
        </bk:book>
        <bk:catalogue isbn="15666529">
            <bk:title>A list of loads of books</bk:title>
        </bk:catalogue>
    </xml>

In this case, 'auto-joining' an attribute to its element's namespace
would make 'isbn' into a *global* attribute. Handy, if you wanted to
process all bk:isbn numbers in a document - but wrong!! In this document
we do NOT have two instances of bk:isbn, we have one of bk:book:isbn and
one of bk:catalogue:isbn.

So after all that, what namespace is it in? Taking on board the points
in section A.2, 'isbn' actually occurs twice, once in the per-element
type partition for bk:book, and again for bk:catalogue. But now, unlike
before, each is guaranteed to be unique, which is what namespaces are
for!

On to the second issue. I think some of the confusions have arisen by
mixing up namespaces with validation. All namespaces do is give you a
syntax for ensuring that elements and attributes are unique. In our
examples above, we don't want to ensure that 'isbn' is unique within the
entire document, we just want it to be unique within 'book' and
'catalogue'. But XML already ensures that, so we don't actually need an
explicit namespace. A parser already has all the information it needs
about the attribute from its context within an element. If an
application processing the nodes in the document had to act differently
when processing 'isbn' fields that come from inside the company, versus
processing the public ones; and further, if 'catalogue' is defined
inside our company, but 'book' is public; then, in the following
document we already have ALL the information we need:

    <xml xmlns='urn:company:books' xmlns:bk='urn:loc.gov:books'>
        <bk:book isbn="1568491379">
            <bk:title>Cheaper by the Dozen</bk:title>
        </bk:book>
        <catalogue isbn="87">
            <title>A list of loads of books</title>
        </catalogue>
    </xml>

The parser will already give us all the information we need to process
the two 'isbn' values differently, even though neither are prefixed with
a namespace! We don't need one!

So hopefully now you can see why this is unnecessary:

	<html:a html:href="x">y</html:a>

this is OK:

	<html:a href="x">y</html:a>
	<html:base href="x" />

and this is not good practice at all (see Andrew Layman's comments on
this, too):

	<html:a html:href="x">y</html:a>
	<html:base html:href="x" />


Regards,

Mark Birbeck
Managing Director
Intra Extra Digital Ltd.
39 Whitfield Street
London
W1P 5RE
w: http://www.iedigital.net/
t: 0171 681 4135
e: Mark.Birbeck at iedigital.net

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)