Re: Use cases

At 11:07 AM -0400 5/17/00, Simon St.Laurent wrote:
>At 06:29 PM 5/16/00 -0700, Michael Rys wrote:
>  >The issue is not really an MS issue. The issue is that a relatively old rec
>>exists that requires literal interpretation of namespaces for equality. Any
>>change to this interpretation, in particular introducing additional
>>processing of namespace uris to determine equality will break current
>>documents and their processing. While we as tool implementors have control
>>over the tools we write, we do not have control over our customers'
>>documents.
>
>15 months is old?  That's okay, you're right.
>
>So let me double-check this.  Microsoft is currently using relative URIs to
>support various XML operations.  This usage works just fine under the
>namespaces rec as currently interpreted - equality by string comparison -
>but may break should relative URIs be absolutized.

Except that this is not exactly the situation, as I have heard it 
explained by other Microsoft representatives. The _meaning_ of 
relative URLs as  used by Microsoft software is based on absolutizing 
the relative URL with respect to the document base and using it to 
retrieve a resource. The comparison semantics defined by the 
namespaces spec. are in fact ignored by this software. The namespaces 
specification defines the matching of namespace URIs for identity, 
and does not mandate or endorse any resolution strategy.

The result is that the Microsoft documents in question depend on 
resolution and retrieval of data from the namespace URI, rather than 
comparison according to the specification -- this means that two 
distinct namespaces according to the URI specification, e.g. 
"foo/../blort/example" and "blort/example" would be treated as 
identical by MS software. Given two documents with namespace 
references like "blort/example" however, one could not tell if the 
assocuiated tags shared semantics _without_ dependable notion of the 
base URI with respect to which those namespace URIs should be 
resolved.

Microsoft has a strong interest in preserving the legality of 
relative URI syntax for namespaces, because otherwise their 
resolution-based strategy really fails, and their documents become 
either non-conformant or deprecated.

They do not have any strong need to preserve the current 
interpretation, because their software uses relative namespace URIs 
as a retrieval hook for a proprietary schema mechanism. This software 
does not use namespace-based comparison to determine a global, 
persistent identifier, in the way that the namespace spec. assumes. 
I'm not trying to put words in anyone's mouth, but I have heard other 
Microsoft representatives speak as strong supporters of making a new 
revision that removes that rule, in the belief that the current 
interpretation doesn't mke much sense in the context of the software 
in question.

The literal comparison strategy is equally unattractive to all people 
who believe that retrieval of a resource is best basis for namespace 
identity testing (with a special case that ensures that identical 
absolute URIs need not be retrieved in order to test identity).

The current comparison semantics makes the use of relative URIs 
pretty pointless for the function of globally identifying elements in 
a namespace (the primary goal of the namespaces spec). However, 
changing that semantics to relfect resolution against a base 
introduces problems as well:

1. James Clark's software relies on namespace comparison, and 
implements namespaces as currently defined.

2. Base URI information has proven (in practice) to be relatively 
fragile, meaning that the "Unique identification" function of 
namespace URIs is not well supported by relative URIs with respect to 
a base.

3. Relative URIs are most useful when a hierarchical namespace is to 
be cloned into many different contexts. This is an infrequent need 
for persistent, globally-unique identifiers.

   -- 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 Wednesday, 17 May 2000 13:17:24 UTC