RE: [046-lc-edit-relative-URI] proposed patch

We have a problem that is over constrained -- it is impossible
to accomplish all of the desired goals of clarity and compatibility
simultaneously. Thus, it is necessary to come to some 'rough
consensus' about which choice to make. This is especially
difficult for changes to terminology that cannot by themselves
be judged by "running code"; when we have no judgment by
"running code", the "rough consensus" is pretty rough.

> Without your change the document defines what a relative-URI is, with
> your change it does not. I consider the terminology part of the tech-
> nology as that is what people use to interact with the technology. It
> is like a public interface in computing, you can rename stuff while
> remaining internally consistent, yet software breaks if you do it.

I think the question of "technology" is whether a change breaks
existing implementations (this doesn't) or just wording in specifications.
We're not actually naming interfaces, just specifications; and
IETF specifications have explicit versions.
 
> There is a broad range of specifications that consider e.g. "/foo" a
> "URI" as defined in RFC2396, RFC2396bis says it is not a "URI", it
> should be obvious that this is not compatible.

No, it isn't 'obvious': it is normally the case that
new specifications can redefine terms if the new definitions
are better. There is no requirement that terms keep their
definitions as specifications move forward, if the redefinition
doesn't affect software, just documentation. Old programs whose
documentation says "X is a URI - in absolute or relative URI"
will need to have their documentation fixed. Old programs whose
documentation says "You can type a URI into the address bar"
yet don't allow you to type a relative path into the address bar --
their documentation won't have to change.

> Similar for "#x", per
> RFC2396 this is not a relativeURI, draft-fielding-uri-rfc2396bis-06
> considers it a relative-URI, that is obviously not compatible either.

If definitions of terms in specifications were required to
be "compatible", we could never make any changes to any specs
at all!   No software is affected by the changes in definitions.
Other specifications which currently cite RFC 2396 may have to
be edited in order to properly cite RFC2396bis, but this is
an editorial task for the editors of documents, not a software
task for the implementers of software.

> Sorry but I am unable to find any evidence that considering 
> "/foo" not a URI is in any way common in specifications,

In some specifications, but in others, it is defined otherwise.
We must make a choice, and cannot allow both a constrained
and unconstrained definition. The choice is editorial, and after
two years of deliberation, we've made the choice that makes the
most sense given all of the constraints.

> implementations, 

This is a different matter. I have some software that uses
the word "integer" to mean "a 32 bit number". Certainly the token "integer"
in my program doesn't really mean "integer" in the mathematical
sense. So, just because many programmers have used the token
"URI" in their software to mean "URI or relative path" does
not constrain what the definition of a URI should be.

> or other common usage.

I suppose we should have some concern about common usage in
newspapers and so on, but frankly, I think in common usage,
if I ask you "do you have the URI for that newspaper article",
I would be very unhappy if you were to give me a relative path!
In the cases I can think of, 'common usage' is more in line with
the current direction than not (although URL is more in
common usage than URI, for that matter).

>  My experience is exactly the opposite. If you could point
> out software that throws syntax error exceptions when passing "/foo" to
> what expects a URI that would be helpful, but it seems rather unlikely
> to me that such software constitutes a vast majority in any sense.

I have software that fails to function when I pass it
200000000000000000000000000 as an "integer", even though
200000000000000000000000000 is definitely an integer.

Software that uses XML Schema will 'anyURI', which includes URIs,
relative paths, and IRIs. It doesn't mean that anything that
satisfies the schema constraint 'anyURI' is a URI.

In summary:

The editorial problem of the definition of terms is over constrained;
there is no way to satisfy all of the desired properties. After an
enormous amount of deliberation and discussion, we've made a choice.
I believe this choice is the best solution, considering all of the
constraints.

Larry
-- 
http://larry.masinter.net

Received on Friday, 17 September 2004 17:21:31 UTC