Re: [XML-URI] HTTP extensions framework comparison

At 10:20 AM 7/20/00 -0700, Henrik Frystyk Nielsen wrote:
[John Aldridge]
>> I beg to differ.  I believe this to be behaviour which should be
>> standardised, and not left implementation defined.
>
>It is - the URI spec already defines the normalization rules for the most
>commonly used parts of current URIs and if so you care about this then you
>should implement the URI spec or pick your URI space appropriately so you
>don't run into this problem. Let me point out again that we can not change
>the rules in each and every spec that uses URI - that would lead to true
>lack of interoperabilility.

I'm sorry Henrik, but what is presently available is scattered,
scheme-dependent, and violently unpredictable relative to the kinds of
expectations people have for processing XML documents.

The really nice thing about XML is that different processors return the
same picture of a document, or should.  Determining whether content and
structure match a given set of rules or are identical between documents is
well-defined and reasonably easy.  Predictability is one of the largest (if
quietest) advantages XML provides.

(Yes, I know there are exceptions - see:
http://www.simonstl.com/articles/interop/ )

The rules for URI comparison are scattered and various.  I don't consider
any of the proposals put forward for comparing URIs - apart from literal
string comparison - worthwhile as a reliable foundation on which to build
any further.

The rules for HTTP are great if you're concerned about not caching the same
document twice, but a complete and utter waste of time if you're trying to
figure out whether two namespaces are the same.

I've said this repeatedly, and hope not to have to say it yet again.
Either put a real comparison mechanism into a revision of RFC 2396, or
settle for simple and straightforward literal comparison.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
http://www.simonstl.com - XML essays and books

Received on Thursday, 20 July 2000 14:15:26 UTC