W3C home > Mailing lists > Public > www-tag@w3.org > May 2008

Re: [widgets] Widgets URI scheme

From: <noah_mendelsohn@us.ibm.com>
Date: Thu, 29 May 2008 22:32:04 -0400
To: Tim Berners-Lee <timbl@w3.org>
Cc: Norman Walsh <ndw@nwalsh.com>, www-tag@w3.org
Message-ID: <OFA82D87B2.B5904EE2-ON85257459.000D4990-85257459.000DD090@lotus.com>

Norm Walsh wrote:

> The media type returned by .../blink-01.zip

I wrote:

> Doesn't reliance on media-type suggest a # as opposed to / as 
> separator,
> as in:
>
>        http://example.com/sample.zip#outer/inner/deepest

Tim Berners-Lee replied:

> No, so the server would
> 
> *either* unpack the item and return it, (200)

I agree that this is something a server could do with a URI like:

        http://example.com/sample.zip/outer/inner/deepest

What I'm puzzled about is that Norm had specifically proposed reliance on 
the media type that would result from a retrieval of:

        http://example.com/sample.zip

and I don't see how that enters into the case where the server does the 
unpacking and returns a 200 for the "deepest" item.

> *or*  return metadata explaining what is going on, so that the client 
> can retrieve the zip file  (303)

Yes, but I don't think we have a widely deployed and interoperable 
standard for that particular metadata, do we?  Of course, RDF gives a 
framework, but until some particular ontology is agreed, and until widely 
deployed user agents act on it to retrieve and crack the zip file, this 
doesn't work in practice.  To some degree the same criticism would apply 
to use of "#" and a zip-related media type, but at least many user agents 
have pluggable handers for new media types.

> *or*  return metadata explaining what is going on, with the zip file 
> (TBD)

Same concern.

> Tim

Noah

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








Tim Berners-Lee <timbl@w3.org>
Sent by: www-tag-request@w3.org
05/29/2008 04:51 PM
 
        To:     noah_mendelsohn@us.ibm.com
        cc:     Norman Walsh <ndw@nwalsh.com>, www-tag@w3.org
        Subject:        Re: [widgets] Widgets URI scheme




On 2008-05 -29, at 16:33, noah_mendelsohn@us.ibm.com wrote:

>
>> The media type returned by .../blink-01.zip
>
> Doesn't reliance on media-type suggest a # as opposed to / as 
> separator,
> as in:
>
>        http://example.com/sample.zip#outer/inner/deepest
>
> My quick reading of RFC 3986 suggests that this syntax is legal in a
> fragid.  Of course, it has the characteristic that only the 
> identifier of
> the zip container is typically sent "on the wire".   I don't see how 
> the
> media type spec can help you crack:
>
>        http://example.com/sample.zip/outer/inner/deepest
>
> As Stuart says, that URI is opaque, and a client would not in 
> general have
> knowledge of the relationship of those last 3 components to zip 
> packaging,
> I think.


No, so the server would

*either* unpack the item and return it, (200)

*or*  return metadata explaining what is going on, so that the client 
can retrieve the zip file  (303)

*or*  return metadata explaining what is going on, with the zip file 
(TBD)

Tim
Received on Friday, 30 May 2008 02:32:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:57 GMT