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

RE: Use cases

From: David G. Durand <david@dynamicdiagrams.com>
Date: Thu, 18 May 2000 10:37:08 -0400
Message-Id: <a04310102b549af11ad2f@[]>
To: <xml-uri@w3.org>
At 4:01 PM -0400 5/17/00, Julian Reschke wrote:
>So if we are not talking of MSXML as such -- what else is to consider?
>Applications built on top of XML processors are free to treat URIs in
>namespaces any way they want. If an hypothetical MS application treats two
>namespaces as identical, because their URIs, which are not identical
>strings, actually DO point to the same URI -- where's the issue? This is
>explicitly allowed in the namespace recommendation.

Comparison of relative URIs by resolution with respect to a base is 
explicitly _not_ allowed by the namespaces recommendation, which 
presents an algorithm for performing such comparison: literal string 
comparison, to be precise. Some think that this is a good (or at 
least acceptable) thing e.g. me, Microsoft, others that it's a bad 
thing, e.g.  Tim Berners-Lee, Dan Connolly.

This has been exhausitvely, and exhaustingly discussed once by the 
relevant W3C groups, which have already voted to leave things as they 
are. So far, I've seen no new arguments, nor really any reason that 
this discussion should be continuing.

>Could please someone who *REALLY* knows which "existing documents" are
>affected give an example?

I don't believe that we've ever seen a concrete instance of a real 
independently created document that has this problem. However, since 
it would almost by definition be generated by someone isolated from 
the standards community, the nonexistence of such documents cannot be 

   -- David
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
http://cs-people.bu.edu//dgd/             \  Chief Technical Officer
     Graduate Student no more!              \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
Received on Thursday, 18 May 2000 10:46:00 UTC

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