Re: Request for status dump and issues check

Quoth the honorable Mr. Berners-Lee:
>I have also shifted ground in that rather than simply insisting on
absolutizing, I can see we may have to compromise with
>banning relative URIs, because the interpretations of them
>are simply inconsistent.

I think all of us (myself included) have finally started realizing that
this is _NOT_ a trivial problem, and that all the proposed answers really
have had significant costs associated with them as well as benefits.


>1)  Namespace references are  URI-references according to the spec.
>..
>  The bit in the Namespace Recommendation about character-for-character
>comparisons
>  was wrong because no one had then spotted that it provided
inconsistencies
>with
>  relative URUI references.

There's a conflict there, agreed. This proposal reverses prior intent,
which Tim Bray has stated was equivalent to your Option 3.

I can see _why_ you want to reverse the intent; it permits the Namespace
Name to become a URI with all the benefits and baggage thereof. (Which you
might want to explain to folks, so we have  a better idea of why this is
considered important -- I know I don't understand them well.) In that
scenario the namespace declaration to become a reference to that URI, with
all the baggage _that_ implies.

Downsides: What if there's no base URI. Are we happy with weak inequality.
Do we want to spend cycles on something for which a need has not been
established.


>2) Namespace references are URI-references but the use of relative-URIs is
>  not allowed in a conforming document.  The results of using one are
>undefined

Essentially, this is a deprecation -- while reserving the right to
reintroduce relative syntax later if/when a strong case can be made for it.
Leaving it undefined does provide a path for those who are already using
that syntax. Folks who want to invest the cycles can absolutize, folks who
don't can issue warnings/errors or treat them as literal.

This minimizes the impact on existing code and documents... which may be a
bad argument from a comp-sci perspective but is a very good one from a
software engineering standpoint.

I think this one has a real chance of getting off the ground. It's
something we can agree on _NOW_, so the specs which are hanging fire can
proceed.

(However, I don't think one should assume that full relative-reference
support will be added in XML 2.0. I think it's certainly worth further
discussion, but it's going to have to justify itself under the 90/10 rule.
For that reason alone, deferring it makes sense; its proponents really need
time to establish a compelling family of usecases.)

This solution needs a short name for further discussion. I propose
"Deprecate/Undefined", or one of those two keywords.


>3) Namespace names look like (have the syntax of) URI references but are
not.
>I could not live with that.

I believe those of us who favored this Literal reading would be willing to
accept Deprecate/Undefined (your #2).

<grin>We may or may not resume arguing when a definition _is_ proposed in
the XML 2.0 timeframe, of course, depending on what that proposal is and
how well it's justified, but that's business as usual.</grin>


______________________________________
Joe Kesselman  / IBM Research

Received on Thursday, 8 June 2000 11:55:15 UTC