[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

• From: Mark Birbeck <Mark.Birbeck@i...>
• To: XML List <xml-dev@i...>
• Date: Fri, 5 Feb 1999 14:04:42 -0000

> 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.

Reminds me of a question I had a while back: what happens to a perfectly
acceptable  XML 1.0 document run through an XML parser which has a
namespace processing module? This is, after all, valid XML 1.0:

	<this:is:my:good this:is:an:attribute:called:a1="1" />

(As is:

	<:::: :::="1" />

)

In terms of the old document run through the new parser, as far as
namespaces go this should be no different to:

	<good a1="1" />

But in the new parsers it will be an error, because, as the spec says,
"The namespace prefix, unless it is xml or xmlns, must have been
declared ..."

It seems that XML namespaces are not backwards compatible with 'old'
documents. If this is true, is it explicitly justified anywhere? I
haven't come across it. Perhaps it is the intention of the spec that a
'non-conformant' document (i.e., more than one colon in names, etc.)
simply 'drops back' to XML 1.0, rather than being 'failed' by the
namespace processor. But this then means you couldn't merge two DTDs in
a document - one built with namespaces in mind, and one not.

Maybe another approach is that if a prefix is *not* declared using an
xmlns tag then the prefix and its local name are to all intents and
purposes just one name. This would allow you to mix DTDs, as I mention,
but would then mean you don't have 'conforming and non-conforming'
documents, you have 'conforming and non-conforming' elements - but it
would work.

And maybe none of this matters and we're just assuming that XML is
'young' enough for us to catch the problem early, everyone is already
starting to conform, and in which case on completion of the namespaces
spec we would have to declare XML 1.1, and say that it is *not*
backwards compatible.

Anyway, I would be interested to know if anyone has seen an explicit
reference to this - either saying I'm wrong and namespaces *are*
backwards compatible, or justifying why it is OK to not be backwards
compatible.

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@i...


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
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@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • Re: Namespaces does *not* formally introduce "global attributes"
    • From: Tyler Baker <tyler@i...>
  • RE: Namespaces does *not* formally introduce "global attributes"
    • From: David Megginson <david@m...>

• Prev by Date: Re: SAX, Java, and Namespaces (was Re: Restricted Namespaces for XML)
• Next by Date: Re: A weaker XSL?
• Previous by thread: Fw: Namespaces does *not* formally introduce "global attributes"
• Next by thread: RE: Namespaces does *not* formally introduce "global attributes"
• Index(es):
  • Date
  • Thread