W3C home > Mailing lists > Public > xml-names-editor@w3.org > August 2002

Re: A plea for Sanity

From: Joe English <jenglish@flightlab.com>
Date: Wed, 21 Aug 2002 19:20:34 -0400 (EDT)
Message-Id: <200208212319.g7LNJx330611@dragon.flightlab.com>
To: Norman Walsh <Norman.Walsh@Sun.COM>
Cc: xml-names-editor@w3.org, w3c-xml-core-wg@w3.org

Norman Walsh <Norman.Walsh@Sun.COM> wrote:

> The Core WG has considered your comments[3] on XML Namespaces 1.1.

Thank you.

> > In particular, "additional namespace information items which
> > serve no useful purpose" -- and hence do not affect the interpretation
> > of QNames in markup or content -- should not matter. [...]
> In the best of all possible worlds, you're right. The set of namespace
> declarations and in-scope namespaces should be irrelevant. But in
> point of fact, the existence of QNames in content adds great
> complexity to task of determining the semantics of an XML document.
> Some of these complexities are discussed in the TAG[1] finding "Using
> Qualified Names (QNames) as Identifiers in Content"[2].
> In particular, changing the set of in-scope namespaces for a given
> element may effect a change in the semantics of that element, its
> attributes, or its descendants to some down-stream processor. As much
> as we might wish that that were not the case, it appears impossible to
> circumvent at this time.

I'm afraid this misses the point.  Undeclaring an unused
namespace prefix *cannot* change the interpretation of any
element names, attribute names, or QNames in content.
Since undeclaring a namespace prefix which *is* used
would cause an error, there is no compelling reason
to support this feature.

Unless the WG disagrees with the proposition that:

> > [A]ny set of namespace declarations that produce the same
> > {URI+localname} pairs after namespace processing should be considered
> > equivalent.

and if this is the case, I urge the WG to reconsider,
for reasons previously stated.

--Joe English

Received on Wednesday, 21 August 2002 19:58:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:56:48 UTC