W3C home > Mailing lists > Public > xml-uri@w3.org > May 2000

Attribute uniqueness test: a radical proposal

From: Paul W. Abrahams <abrahams@valinet.com>
Date: Sat, 27 May 2000 15:54:31 -0400
Message-ID: <393027F7.A785649B@valinet.com>
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"
           <mumble a:x="1" b:x="2">

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>

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

Paul Abrahams
Received on Saturday, 27 May 2000 15:55:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:59 UTC