RE: referendum on httpRange-14 (was RE: "information resource")

Patrick,

I would have to disagree with this statement.  Fragment identifiers can
be used in an efficient and scalable manner using the HTTP "Range" header.

I published on this topic at the 2004 Extreme Markup conference [1].

The fast summary is that the HTTP Range header can be used specify a
logical "sub-resource" address using an extensible addressing scheme
(the HTTP "range-unit").  The paper explored the use of the Range header
to provide scalable and extensible subresource addressing for URI fragment
identifiers.  While this paper focused on the Xpointer Framework, the
technique is not limited to the XPointer framework.

The only cost for an HTTP client is the trivial effort of constructing
the appropriate HTTP Range header from the URI Fragment identifier.

[1]
http://www.mulberrytech.com/Extreme/Proceedings/html/2004/Thompson01/EML2004
Thompson01.html


Thanks,

-bryan

Patrick Stickler writes:

> Forced indirect access to representations via
> URIrefs with fragment identifiers is inefficient
> and non-scalable. Yes, it can work in some cases,
> for some applications, for some data. But it is
> *not* a scalable solution for the future of the
> web and semantic web.

-----Original Message-----
From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of
noah_mendelsohn@us.ibm.com
Sent: Wednesday, October 20, 2004 10:41 AM
To: Patrick.Stickler@nokia.com
Cc: Norman.Walsh@Sun.COM; sandro@w3.org; timbl@w3.org; www-tag@w3.org
Subject: RE: referendum on httpRange-14 (was RE: "information resource")



Patrick Stickler writes:

> Forced indirect access to representations via
> URIrefs with fragment identifiers is inefficient
> and non-scalable. Yes, it can work in some cases,
> for some applications, for some data. But it is
> *not* a scalable solution for the future of the
> web and semantic web.

With the caveat that I'm still coming up to speed in this long-running 
debate and have not formed firm opinions, I have some sympathy with the 
particular statement above.  There is at least conceptual and perhaps 
operational overhead in requiring that one resource be indirectly 
identified as secondary to another, unless that relationship is for other 
reasons natural.    That doesn't by any means settle the httpRange-14 
question, but I agree with the point taken in isolation. 

That said, my understanding is that the TAG has in Basel suggested a way 
forward, documented in the draft minutes at [1].  Specifically: 

"RESOLVED: to drop [I.e. from the Architecture Document draft...Noah] the 
HashSlashDuality text (section 2.2.1 and descendants in a draft that was 
projected) and use as input to finding on HTTPrange-14, DC, TBL 
abstaining. ACTION DC: with Norm, develop a finding on httpRange-14 
starting with the HashSlashDuality text"

I suggest that many of the important points on both sides of the debate 
have been made (perhaps more than once?) in this email thread, and thus my 
preference would be to back-burner the email  discussion until some 
progress is made on a draft finding.  Then we'll have something concrete 
to debate and tune. 

Noah

[1] http://www.w3.org/2001/tag/2004/10/05-07-tag#infores234

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Thursday, 21 October 2004 20:02:56 UTC