- From: Paul W. Abrahams <abrahams@valinet.com>
- Date: Sat, 27 May 2000 15:54:31 -0400
- To: xml-uri@w3.org
Perhaps the way out of the namespace name quandaries is to take a different tack entirely: replace the uniqueness test of Sec. 5.3 by the following: In XML documents conforming to this specification, no tag may contain two attributes that: 1. have identical names, or 2. have qualified names whose local parts are the same and whose prefixes are bound to the same namespace declaration. With this approach, the comparison does not require any consideration of the namespace names at all. Incompatible, yes. But not in the sense of invalidating a single existing document. The effect of this change is to allow attribute combinations that are disallowed under the current specification because they aren't unique. No presently allowable attribute combinations are disallowed. The case for this change is based on the observation that many folks here have made that although the attribute uniqueness test may find certain bad combinations, it cannot guarantee that all of them will be found. For example, suppose that http://www.smith.org/docA is just a mirror of http://www.jones.org/docB. Then the following document certainly violates the intent of uniqueness, but there's no way the violation would ever be found in practice: <gobble xmlns:a="http://www.smith.org/docA" xmlns:b="http://www.jones.org/docB"> <mumble a:x="1" b:x="2"> </gobble> The uniqueness test is best thought of as catching the obvious ``no'' cases, leaving all the others as ``maybe''s. Note that in the following document: <gobble xmlns:a="http://www.smith.org/docA" <mumble a:x="1"> <squawk xmlns:a="http://www.jones.org/docB" <mumble a:x="1" a:x="2> </squawk> </gobble> the two a:x attributes on the fourth line violate the uniqueness constraint. Despite the outer declaration of xmlns:a, these two attributes are guaranteed to refer to the same thing. This approach also solves the vexing problem of relative URIs used as namespace names within the scopes of different xml:base attributes. No matter what xml:base attributes happen to be in the document, the only comparisons that matter are those among the attributes of a single element, and in that context only one xml:base attribute can apply. So even in this case we aren't excluding attribute combinations that might make sense. It seems to me that this approach cuts the Gordian knot entirely. Paul Abrahams
Received on Saturday, 27 May 2000 15:55:07 UTC