xml-dev - RE: 5.3 and Appendix A contradiction [Re: Another errata?]

[Mark Birbeck <Mark.Birbeck@iedigital.net>]

james anderson wrote:
> John Cowan wrote:
> > 
> > Mark Birbeck wrote:
> > 
> > > 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.
> > 
> > Well, not quite.  An element can have the same name as a global
> > attribute without problem.
[I've replied to this in the 'Another errata?' thread]

> In a similar vein, one unqualified attribute defined for one 
> element can have
> the same name as another unqualified attribute of another 
> element without
> sharing the same declaration.

A very odd response! Follow the three comments through:

- in response to demands for more errata I say that an unqualified
attribute should *not* automatically join the namespace of its element
- as part of my justification I say that all members of a namespace must
be unique, and then go on
- John disagrees - although why I don't know, because that's what a
namespace is - and backs up his argument by saying that an element and a
global attribute can have the same name. But that doesn't prove that
namespaces can have duplicates, because they are actually in different
namespaces
- and then James comes to his assistance by adding that an unqualified
attribute for one element can have the same name as an unqualified
attribute on another element

BUT WHY?! Well ... because an unqualified attribute does not
automatically join the namespace of its element!! If it did then you
would have duplicates in your namespace, because they are different
attributes. Sound familiar?

> More than one kind of "namespace" is necessary to interpret 
> an xml document
> which conforms to the spec. One kind of space maps QName's 
> and Name's to
> identifiers.

If we're going to pursue this to the bitter end ... you can't have a
'Name' in a conforming doc, they must all be 'QNames' (no colons except
after a prefix).

> The namespace spec itself does not do justice to this, and, in fact,
> introduces - in relation to the notion of universal attribute 
> names - the
> impression that XML requires a Name -> Identifier -> 
> Attribute-Declaration
> mapping/namespace, when it does not. While one could accept 
> that the illusion
> of such a namespace is helpful for things like XSL patterns, 
> this kind of
> namespace is not entailed by the xml spec itself. It 
> specifies a mapping of
> the form Name -> Identifier -> Identifier -> 
> Attribute-Declaration. That is,
> it requires an element identifier in addition to an attribute 
> identifier in
> order to identify a declaration.

This may be true - that XML does NOT require this - but I think the spec
rightly draws attention to its need in many applications. Take for
example the difficulty of dealing with global attributes. Say that I
want every single node in a magazine article to have a unique identifier
so that if it gets edited I can put it back into the database easily. I
might define:

    <xml xmlns="uri:magazines-r-us" xmlns:db="uri:mydatabasespec">
        <article db:id="1">
            <title db:id="2">My Article</title>
            <paras db:id="3">
                <para db:id="4">An interesting thingy.</para>
                <para db:id="5">More of the same.</para>
            </paras>
        </article>
    </xml>

Without the namespace spec, 'id' is in four different namespaces. Now
you're right that each has context:

    article->id
    article->title->id

and so on, but I disagree with you saying that this contextual
information 'is enough'. What if I wanted to process all database 'id'
values? Say my application needs to work out if any nodes have been
deleted before returning the data to my database. Well OK, you could
say, in XSL-style syntax:

    */attribute(id)

or whatever it is. That is - give me all elements that contain an 'id'
attribute. But what if we were to add an additional 'id' attribute, say
for use by some other site to allow paragraphs to be quoted. And say
also, that it was not a requirement of each node to have a database 'id'
value. Then without namespaces we get:

    <xml>
        <article id="1">
            <title id="2">My Article</title>
            <paras id="3">
                <para id="a1p1">An interesting thingy.</para>
                <para id="a1p2">More of the same.</para>
            </paras>
        </article>
    </xml>

Now my poor old database application cannot tell the difference between
the database version of 'id' on 'article', 'title' and 'paras' and the
reference version of 'id' on 'para' - unless of course we process every
single node that comes back from the '*/attribute(id)' query, or we
query for each of the possible types.

But with namespaces I can say 'give me every id value in the
uri:mydatabasespec namespace'. Of course, you could argue that I should
just name my attributes something else - 'db:id' perhaps - and then I
can query them uniquely. But what if I want to use two DTDs, and someone
else has used 'db:id'? I'm back to square one again. Whichever way you
turn, if you want to assist applications built on an XML processor - and
I believe 'assist' is all that is being said in the spec - namespaces
are very, very handy.

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@iedigital.net


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