Re: Use cases

I'd like to look in more detail at the question as to whether any actual
damage would occur were the NS spec to changed to require
absolutizing for comparison. I contend that, because in fact that is
consistent with URI behavior, it will not cause problems with existing
documents in practice.

-----Original Message-----
From: Michael Rys <mrys@microsoft.com>

>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 give misleading results, comparing 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 skeptics about the problems with transition here.

> While we as tool implementers 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 suggest that anything which passed well-formedness before
and fails after was bound to fail at a later date anyway when dereferencing
occurred.

>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 explain that there is a bug when using relative
URIs
sometimes.  And people 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 discussions, the namespaces Rec.
will be reissued clarifying the decision. It will of course get a different
version number.
I contend that if we go with "absolutize" we will be increasing the
consistency and
not creating new bugs.  So it is not a path of great pain. I also believe it
is the right
thing to do.

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:54:45 UTC