- From: Tim Berners-Lee <timbl@w3.org>
- Date: Wed, 17 May 2000 19:53:04 -0400
- 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