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

Re: moving toward a decision

From: <keshlam@us.ibm.com>
Date: Wed, 5 Jul 2000 11:57:18 -0400
To: David Carlisle <david@dcarlisle.demon.co.uk>
cc: xml-uri@w3.org
Message-ID: <85256913.0057A972.00@D51MTA03.pok.ibm.com>
>xpath and infoset similarly unspecified
>not as previously suggested infoset unspecified and xpath data model
>with a specified behaviour

I must have been looking at the wrong copy of the proposal, then. Thanks;
that addresses one of my concerns.

>Joe Kesselman's original suggestion was much closer to "forbid" than
>this, I think.

Probably, though I'm not sure which of several scenarios was being
discussed at the time. The one we're currently looking at seems closes to
the Deprecate/Undefined proposal; while I would personally prefer Forbid, I
can see the argument for not breaking existing code unless absolutely

>somewhat strange approach for a putative standards making body to
>make that given a situation that all known implementations operate in
>an inter operable manner that the behaviour should be declared

Don't confuse serendipitous and specified interoperability. The latter is
guaranteed (assuming correct implementations), the former isn't.

There's a basic principle that simple agreement of the implementations we
know about does not, by itself, resolve an "unspecified" point in the spec.
Parallel evolution and similar solutions may yield similar behavior for
most implementations... but the next may find that its needs are best
served by deciding the other way, and it's no less "right" in doing so.

If you really want to nail something down for interoperability, go back to
the Working Group(s) and propose an official solution. But it's legitimate
for them to reject the proposal if they're concerned it may excessively
constrain future code.

Joe Kesselman  / IBM Research
Received on Wednesday, 5 July 2000 11:58:12 UTC

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