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

Re: Use cases

From: Tim Berners-Lee <timbl@w3.org>
Date: Wed, 17 May 2000 19:53:04 -0400
Message-ID: <00df01bfc093$4a71ca00$b0ec5c8b@ridge.w3.org>
To: "Michael Rys" <mrys@microsoft.com>, <xml-uri@w3.org>

-----Original Message-----
From: Michael Rys <mrys@microsoft.com>
To: 'xml-uri@w3.org' <xml-uri@w3.org>
Date: Tuesday, May 16, 2000 9:30 PM
Subject: Re: Use cases


>>Is there a local Microsoft XML weenie here?
>
>There are several Microsoft XML people here. <grumble>Should I get
offended,
>or not?</grumble>
>
>>'software' is awfully vague, and doesn't tell me which 'weenie'. I've
never
>
>>seen this behavior in my uses of Microsoft's XML tools, but it may just be
>>that I haven't wandered into the right pasture.
>
>The main scenarios that I am aware of is to refer to inline XDR schemas and
>inline XSLT function extension mechanisms. The schema references may be
>hand-authored or generated by some of the XML and ADO XML database tools.
>Both scenarios do not care about the actual string value but are used for
>resolution. However, see below!
>
>>Also: has anyone else (non-MS) done this?
>
>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.

Convince me.  If the URIs are actually resolved then they must be valid
relative URIs. They must absolutize to a valid and correct absolute URI.
If comparing the relative URIs didn't cause any problems, copmaring the
absolute URIs certainly won't.  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 septics about the problems wiht transition here.

> While we as tool implementors have control
>over the tools we write, we do not have control over our customers'
>documents.


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.

>In general retroactive spec changes would be acceptable "if possible",
>namely:
>
>1. retroactive changes have virtually no impact on the conformance of
>existing documents (e.g. loosen constraints, not tighten),


I would suggets that anything which passed well-formednes before
and fails after was bound to fail at a later date anyway when dereferencing
occured.

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

>3. that changes larger than these employ a versioning mechanism,
>4. that a new version have compelling feature benefits to drive adoption by
>vendors and customers.


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.

>In the specific case being considered, none of these conditions appear to
>obtain, and thus changes to the NS recommendation should not be considered
>as a possible option.


Your current software is quite inconsistent in that it uses them as relative
URIs
at one moment and strings the next. In fact, it only runs because none of
your
users have tried the rather obscure test cases which have been generated to
show
this inconsistency. But one day they will. One day, some document will fail
a well-formedness test even though it has been quite properly constructed
with
pointers to completely valid URIs of real schemas.  Two namespaces will have
different
URIs but happen to be declared in contexts such that the relative URIs are
in fact the same.The two namespaces will have to happen to
have attributes of the same name and some actual instance will have to
happen to
validly use both attributes on the same element.  I bet it hasn't happened
yet.  But one day. The document will fail the
well-formedness test though quite valid. That will be a bug.
If you don't fix it now then you will have to explain this problem in great
detail
to your poor users, or just exaplin that there is a bug when using realtive
URIs
sometimes.  And peole will shake their heads and wonder, "how did all these
people end up with such a mess?" and maybe I will write the book.

Fix it now. Get it right!

>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 discussins, hte namespaces Rec
will
be reisuued clarifying the decision.

Tim BL

>Best regards
>Michael "Weenie" Rys
>
>PS: My apologies for answering this late, but I am at WWW9 and reading mail
>once or twice a day at most.


likewise -- me too.
Received on Thursday, 18 May 2000 02:33:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:42 UTC