Fw: Namespaces does *not* formally introduce "global attributes"

[Oren Ben-Kiki]

>Oren Ben-Kiki writes:
> > AHA! So the namespaces proposal _DOES_ go beyond simply qualifying
> > names with URIs!

David Megginson <david at megginson.com> wrote:

>No it doesn't.


Well it certainly got a lot of people confused about it. Luckly we are only
wasting bandwidth as a result, instead of rain forest products :-)

>The comment to which Oren is replying contains a common (but
>understandable) mistake. ...
> The source of the misreading is the unfortunately obfuscatory appendix
>A.2, ...
>I will recommend dropping A.2 in future drafts.


That would be a relief :-)

>In any case, what does all this have to do with transformation?


Simple - if the XML namespaces recommendation was defined by an equivalence
to a well defined textual transformation, then much confusion would have
been avoided. For example, how namespaces interact with the other XML
standards  - just extend the names first, then apply the other standards
(with a very small number of exceptions, such as namespace patterns in XSL).

Additionally, implementers would have been able to easily add a namespace
processing module on top of their current XML parsers (a SAX namespace
expansion filter, for example, is trivial when implemented this way),
_without changing the interfaces_. Future implementations might use better
interfaces - such as APIs for accessing just the "namespace part" or the
"local part" of an expanded name - but the point is every XML application
would go on working as it is, without any changes.

James has mentioned in his paper the WG has deliberately decided not to go
this way. Could you tell us why this decision was made?

An obvious consequence of this decision is that implementers were hesitant
to implement namespaces this way. I hope this wasn't the reason :-) This
happened because first, it wasn't clear that this approach is in fact
conformant. Well, we got this out of the way - James says it is and you
explained why (ignore the non-normative Appendix A). Second, because
competing textual forms were suggested (the '^' notation, the '{}'
notation). Since the WG wasn't kind enough to give us a standard notation,
why can't we just pick one on our own and go with it? I'm partial to the '^'
notation, myself, since it is (i) shorter, (ii) easier to read, (iii)
slightly easier to process, and (iv) more in tune with the conventional
hierarchy naming schemes (using a separator instead of parenthesis).

Actually, has anyone already written a SAX filter which implements
namespaces this way? Is anyone interested? Let's settle this once and for
all - "proof by implementation" :-)

Have fun,

    Oren Ben-Kiki



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/ and on CD-ROM/ISBN 981-02-3594-1
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)