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

[we could probably take further discussion of this to another list]

> -----Original Message-----
> From: www-tag-request@w3.org 
> [mailto:www-tag-request@w3.org]On Behalf Of
> ext Thompson, Bryan B.
> Sent: 21 October, 2004 23:03
> To: noah_mendelsohn@us.ibm.com; Stickler Patrick 
> (Nokia-TP-MSW/Tampere)
> Cc: Norman.Walsh@SUN.COM; sandro@w3.org; timbl@w3.org; www-tag@w3.org;
> Bebee, Bradley R.; kendall@monkeyfist.com; Bijan Parsia
> Subject: 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].

Actually, you seem to agree 100% with my assertion. 

And in fact, your excellent work in this area reflects strongly on the
significance of this scalability and efficiency problem to many web
applications.

Your approach is specifically designed to alleviate the problems associated
with indirect access to secondary resources, by avoiding the need to first
download the entire representation of another primary resource in order
to extract a (kind of) representation of the secondary resource.

You are simply transferring the MIME-type specific fragment processing
from the client to the server.

Personaly, I think that's great! I think there will be alot of use for
such functionality.

However, it does not in any way offer support for either side of this
debate. With both the restricted model and the general model, there will
be URIrefs with fragment identifiers identifying secondary resources,
and being able to more efficiently access those secondary resources
per fragments of representations which provide information about those
secondary resources will be beneficial.

The approach you propose, is not, however, a better solution than direct
access to representations of arbitrary resources identified by http: URIs.

Directly accessing representations of non-information resources via
http: URIs is already being done today, with existing web machinery,
and can be done with *any* web server without any change whatsoever.
The solution is already there, and already being used.

If your approach would be the only, or primary approach to accessing
(kinds of) representations of non-information resources, the implementational
complexity for web servers would increase dramatically, and all the
complexity of MIME-specific fragment interpretation would be poured
into the mix.

Occams razor strongly supports the general model, where the range of
http: URIs is unconstrained.

Your solution is good. It's useful. But it does not in any way demonstrate
that the general model with unconstrained range of http: URIs is not the
best path forward.

> 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.

Yes, but what of the cost for the server?! The high cost of dealing
with secondary resources is there, no matter how you slice it up.

There will be valid, beneficial, proper uses for secondary resources,
but forcing all non-information resources to be treated as secondary
resources is not the way forward.

Regards,

Patrick


> 
> [1]
> http://www.mulberrytech.com/Extreme/Proceedings/html/2004/Thom
> pson01/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 Friday, 22 October 2004 06:50:42 UTC