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

Re: Attribute uniqueness test: a radical proposal

From: Paul W. Abrahams <abrahams@valinet.com>
Date: Sat, 27 May 2000 22:15:41 -0400
Message-ID: <3930814D.A04DB46E@valinet.com>
To: David Carlisle <david@dcarlisle.demon.co.uk>, XML-uri@w3.org
David Carlisle wrote:

> > In XML documents conforming to this specification, no tag
> > may contain two attributes that:
>
> that attribute test is actually the least of the worries,
> the question is mainly (or as much) about whether
>
> <xsl:template match="x:xxx" xmlns:x="namespace-1">
> in a stylesheet matches
> an element
> <y:xxx xmlns:y="namespace-2"/>
> in a document.

#1 (which you didn't quote) is just what it says now.   The question you
cite as vital is, I agree, vital -- but it's addressed by XSLT, not by
the namespace spec.

> But I don't understand this:
> > 2. have qualified names whose local parts are the same and
> > whose prefixes are bound to the same namespace declaration.
>
> prefixes are bound to namespace names by namespace declarations.
> So if you mean "prefixes are bound by the same namespace declaration"
> then you mean it's the same prefix.

Of course, though I didn't realize that when I wrote it.  In fact, the
whole test #2 is redundant!!

> Even though I don't understand your construct I do understand this
>
> > The effect of this change is to
> > allow attribute combinations that are disallowed under the
> > current specification because they aren't unique.
>
> Al Gilman replied also suggesting that this restriction should go,
> and says
> > And as Paul points out, this is a _compatible_ change.
>
> It doesn't seem very compatible to me.
>
> Currently if you take a well formed XML 1.0 document that complies to
> the namespace spec, then you can normalise the prefixes, using a
> distinct prefix for each namespace used, and linearise the document.
> Without this duplicated attribute restriction this procedure could
> turn a well formed document into a non well formed one.

David, I don't follow this argument.  Could you define your terms for me
here?  Does ``normalize'' mean anything more than what you next say,
namely, modifying nested definitions of the same prefix so as to ensure
that each prefix is defined just once in the document?  And what is the
linearization you refer to?  Can you give an example showing how a
document that is well-formed according to the modified uniqueness test
is turned into a document that is not well-formed?

> > The uniqueness test is best thought of as catching the
> > obvious ``no'' cases, leaving all the others as ``maybe''s.
>
> There are no "maybes" in namespace processing.
> That is the whole point of it.

The ``maybe''s are the cases where attributes are really in conflict
even though the comparison test doesn't show them to be in conflict.
The test itself always says yes or no, I agree.  But if the test says
``no, there's no conflict'', there may still be a conflict because of an
undetected equivalence.  So a ``no'' test result really means
``maybe''.  I believe this is a point others have made also.
[Admittedly, the sense of ``no'' here is the opposite of what I meant by
it earlier: ``no, there's no conflict'' versus ``no, this is not valid
because of a conflict''.]

> But it just makes one incompatible change to the namespace
> rec and doesn't address the question that caused Tim Berners-Lee to
> start this list which is
>
> Does
> <xsl:template match="x:xxx" xmlns:x="foo">
> in a stylesheet match
> an element
> <y:xxx xmlns:y="foo"/>
> in a document if the stylesheet and document are located such that
> the two relative URI references "foo" produce different absolute URI.
>
> The namespace rec, common sense (ie me:-), and user expectations say
> yes.
>
> the xpath spec, James Clark, Tim Berners-Lee and Dan Connolly say no.
>
> That's the knot you have to cut.

I cut the knot by saying that the namespace spec should be silent on the
subject, leaving it up to the XPath spec to handle it in a way that's
most appropriate in that context and is not constrained by anything in
the namespace spec.

Paul Abrahams
Received on Saturday, 27 May 2000 22:15:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:43 UTC