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).

> 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?
 
> 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?

> >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.

> 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?
 
> 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.

> >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?

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.

-- 

Schlingt dreifach einen Kreis um dies! || John Cowan <jcowan@reutershealth.com>
Schliesst euer Aug vor heiliger Schau,  || http://www.reutershealth.com
Denn er genoss vom Honig-Tau,           || http://www.ccil.org/~cowan
Und trank die Milch vom Paradies.            -- Coleridge (tr. Politzer)

Received on Friday, 19 May 2000 11:05:04 UTC