Re: Attribute uniqueness test: a (more) radical proposal

At 03:54 PM 2000-05-27 -0400, Paul W. Abrahams wrote:
>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.
>

For what it's worth, I have sitting here in my rewrite queue a pending
message complaining about the presence of that test at all in "the lower
layers."

It is potentially useful, in a polyglot context such as namespaces support,
to have mixed-namespace environments where attribute repetition is not a
syntax error, but is checked in post-syntactic semantic processing where
one would have the option to accept multiple assertions such as
html:class=<list> and merge the lists.

While document writers could be held responsible to normalize this into one
list, it is not necessarily the best architecture for the syntax to force
that functional allocation on all applications.

It would equally solve the problem to eliminate this content model
assumption and check from the Namespaces specification entirely, and defer
this semantic to later layers. 

And as Paul points out, this is a _compatible_ change.

Al

>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 16:20:48 UTC