Re: now://example.org/car (was lack of consensus on httpRange-14)

>> It isn't necessary for the section on how
>> to use the http scheme as a locator to also define all of the
>> different ways that any locator can be used as an identifier.
>
> It would be useful for the registration of the http scheme to define its
> use, which I believe it does, and see no useful cause to extend that.

It is suicidal for a specification to define how the standard will be used.
People will use them in ways that they find useful.  Consider how many ways
that HTTP is being used today that would have been "disallowed" by such
requirements in the specification.  I would have been burned at the stake.
In any case, if you think that the section "defines its use", then clearly
all the current uses of http URI that are not locators (such as HTTP cache
keys, xmlns, DOI, etc.) must be a figment of my imagination as well.

> So, to summarize, RFC 2616, which includes the registration for the http
> URI scheme, includes no explicit support whatsoever for use of the http
> scheme to identify anything other than HTTP listeners.

Of course not, since RFC 2616 defines HTTP listeners and not what people
can identify with http URIs.  The http scheme definition was supposed to
move into a separate document (with https) at the last revision, but
did not for reasons of editorial convenience.

> I'm a lot happier with:
> http://lists.xml.org/archives/xml-dev/200210/msg00610.html

Go ahead and try to be happy with a model in which people identify
listeners instead of resources.  You will find that your model is
inadequate for describing the impact of time (change) and variant
content within the user-perceived model of hypertext.  Likewise,
you will be unable to explain why http URI can be used to identify
XML namespaces, for which there are abundant examples and proven use.

Why you would be happy with an inadequate model is beyond me.  In any
case, I certainly won't be using it to guide any of my design decisions,
since I already have a model that suffers from none of those limitations.

I've pandered to this broken record too many times already, so I won't
be responding to this thread further.  It is time for folks to shut up
so that we can get some real work done.  If you don't like it, then
go ahead and deploy a better architecture and elect a different TAG
to define it the way it makes sense to you.

....Roy

Received on Thursday, 10 October 2002 23:11:52 UTC