W3C home > Mailing lists > Public > public-swbp-wg@w3.org > June 2005

Re: TAG has resolved httpRange-14

From: Ralph R. Swick <swick@w3.org>
Date: Mon, 27 Jun 2005 12:57:51 -0400
Message-Id: <>
To: Phil Tetlow <philip.tetlow@uk.ibm.com>
Cc: SWBPD list <public-swbp-wg@w3.org>

At 11:35 AM 6/27/2005 +0100, Phil Tetlow wrote:
>... If a URI contains # then
>the producer/author absolutely expects the consumer to accept an
>abstraction break at document level,

And what's more, the HTTP specification says that there's abstraction
boundary at '#' -- the document content type (aka MIME type) is the
authority for instructing the consumer about the interpretation of
the fragment identification (or sometimes known as "view").

>and so deliberately wants to convey a
>document centric view of his/her world.

I don't follow this particular point.

For "information resources" of type application/rdf+xml, we SemWeb
folk are free to specify [1] that fragment ids are one way of crossing the
abstraction boundary from documents to arbitrary things, concepts,
RDF Resources.  But I don't follow how that implies that RDF has
a "document centric" view of a world.

   [1] http://www.ietf.org/rfc/rfc3870.txt

> If its slashes all the way then the
>concept of document has deliberately been dispensed with, whether
>information if dished up in the form of a document or not. But this should
>be obvious.

Not obvious to me at all.  Indeed quite the opposite; the naive view
feels more likely to me to be that slashes represent directories
(or "folders" for the more-recently-innoculated) thus reinforcing
a document orientation.  But perhaps you mean to point out the
trailing slash case, which would seem to more likely denote
the contents of a folder (of documents), even to those who've
never administered an apache server.

> Situations where duality of definition and purpose exists are
>more troubling ... where sometimes a
>resource should be interpreted as a document and others merely as an
>aggregate of useful information fragments.

I think there's broader agreement on the inadvisability of multiple
interpretations that you seem to feel.  The TAG's current resolution
appears to find a navigable path between a URI that names an
information resource and a URI that does not -- but that never the
less is still useful _in the deployed Web_ to return to the consumer
some useful information.

>So, if for no other reason than mediation and in the spirit of crazy ideas,
>how about the notion of using a third URI constructor [to] explicitly denote the
>situation outlined above, where the producer/author deliberately does not
>need/want the consumer to take a particular view on the resource being

I'm somewhat uncomfortable with the higher level of abstraction
to which you're attempting to take us here.  I think it is important
that some part of an author's intent be manifest -- and that the
consumer thereby be able to hold an author/publisher accountable
for it.  However, I am _very_ concerned about the practical
deployment issues of your abstraction in the Web.  It seems to me
that where there are architecturally acceptable solutions that work
with today's deployed Web we should give those solutions much
higher preference.

Received on Monday, 27 June 2005 16:58:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 27 January 2023 01:58:24 UTC