Re: Use cases

-----Original Message-----
From: John Cowan <jcowan@reutershealth.com>
To: Tim Berners-Lee <timbl@w3.org>; xml-uri@w3.org <xml-uri@w3.org>
Date: Friday, May 19, 2000 11:05 AM
Subject: Re: Use cases


>Tim Berners-Lee wrote:
>
>> If comparing the relative URIs didn't give misleading results, comparing
the
>> absolute URIs certainly won't.
>
>Whence this certitude?  If someone is relying on the commitment to
char-by-char
>identity, then they may be using "foo" as a private namespace name in
multiple
>documents, and expecting those namespaces to be identical across documents,
>in clear reliance on the Rec (since "foo" is a valid URI reference in every
>document whatsoever).


In the cases Microsoft mentioned, schemas were bring dreferenced so the URIs
were real.
(I also think most people Out There when given a URI field are likely to
traet itthe way they do a link or an image, frankly)

>> I would suggest that there will not be
>> any actual failure at all. (Possibly, some improved results in that
>> well-formedness checks will better check the real situation).
>> Excuse me joining the skeptics about the problems with transition here.
>
>What can be done, will be done, as the history of HTML shows.  You are in
>the position of telling real users that what a W3C Recommendation
explicitly
>blessed is no longer acceptable.  Why should they not tell the W3C to
>go to Hell?


I am in the very awkward position of having to tell anyone who knows that
the
Namespace spec is a mess. It is interpreted in different ways by different
people.
The literal comparison it explictly calls for is inccompatible with the
description
of the NS attribute value as a URI refernce. Banning relative URIs.

>> However, I would expect your customer to use relative URIs in the normal
>> spec-consistent way rather than try to construct tortured proofs by
example
>> which we have had on this list.
>
>The assumption that a simple name with no / in it means the same across
>documents *is* spec-consistent, for the Namespace Rec blesses it.
>
>> >1. retroactive changes have virtually no impact on the conformance of
>> >existing documents (e.g. loosen constraints, not tighten),
>>
>> I would suggest that anything which passed well-formedness before
>> and fails after was bound to fail at a later date anyway when
dereferencing
>> occurred.
>
>That assumes that people *expect* to be able to dereference simple private
>namespace names.  What if they never do?


Maybe you are right.  Ihave too much of the web mindset.  If they had an
xml mindset they could make that assumption, and XSL would fail.
The people on this list would do so.  I haven't heard anyone mentoin a
specific
example.

>> >2. retroactive changes can be introduced by vendors with minimal
customer
>> >disruption,
>>
>> That I would think would be the case. Much larger changes have been made.
>
>To XML?  To published Recs?  Killing backward compatibility of documents?
>I hope not.


No, to software.

>> We are talking about a move to the way Microsoft customers have been
>> using relative URIs in other contexts for years. This would IMHO go under
>> the heading of bug fix rather than new feature.
>
>What is it that is said to have the bug?

That relative URIs were not dereferenced before comparison in NS 1.0. This
has been fixed in NS 1.1 and software is being distributed to fix this.
This will only affect those who have been using strings which are
syuntactically
relative URIs but which have been treated as being absolute.

>> Your current software is quite inconsistent in that it uses them as
relative
>> URIs at one moment and strings the next.
>
>Microsoft's current software is not the Moral Issue.  Real World documents
are.
>The costs and consequences of keeping, or not keeping, one's solemn
promises
>(issued in the form of a Recommendation) are.


Currenltly there are certainly documents which use relative URIs with the
expectations
of relative URIs. Yes, there may be also some which use them with the
expectations that they
are strings.  If you are right about this then there will be no way to go
without pain.

Morally we have a duty to the future, as well as the past, to make a clean
powerful base for futire work.

>> >Note that a versioning of the XML Namespace spec may be acceptable if
done
>> >right. However, there are other issues associated with that.
>>
>> I think that whatever the outcome of these discussions, the namespaces
Rec.
>> will be reissued clarifying the decision. It will of course get a
different
>> version number.
>
>The *Rec* will get a different version number, fine.  How will we know
which
>*documents* conform to the old or the new Rec?  The only mechanism we have
>for discrimination is the XML version number, changing which breaks all
parsers and
>is only to be done with fear and trembling.  Are we ready for that?


This wouldn't help anyway, if as you suggest there are documents whose
athors thought that
they were NS 1.0 compliant but which used the two different interpretations.

>We could of course invent a new mechanism, like an XML-Namespace-Version
>declaration (attribute, PI, whatever).  Maybe it's time to think about
>that.  Every MIME-compatible email message, for example, has a
>"MIME-Version: 1.0" header, not because we ever expect to have a new
>version of MIME (it works well enough and has a huge installed base),
>but because when MIME was first issued, the "Content-Type" header already
>existed with incompatible semantics (see RFC 1049).  That use of
>"Content-Type" is long forgotten, but backward compatibility demanded
>that there was some way to distinguish RFC-1049-compliant messages from
>MIME ones.


If no one on this list can come up with an example where relative URIs have
to be
trated as strings or the document will break, then maybe it could be a small
problem.
But your are right. The pain might be inescapable.  I so wish I had jumped
into this
with both feet when the NS spec came out.

Tim

Received on Saturday, 20 May 2000 19:18:19 UTC