Re: Making MGET more GET-friendly?

On Mar 10, 2004, at 00:11, ext David Powell wrote:

>
>
>
> I'm unsure about MGET because it seems to segment URI space, so that
> applications that deal with data and metadata need to know whether
> they should be using GET or MGET.

Er. Sorta like applications knowing whether to use GET or PUT
depending on whether they are requesting a representation or
submitting a representation?

Seems that the distinction between (arbitrary) representation
of a resource and concise bounded description of a resource
is pretty straightforward for applications to keep clear about.

> This isn't possible for applications
> such as HTML, XSLT, Babelfish, archive.org, etc..

???

I don't follow. Example?

>
> I think that it is valuable for metadata to be obtainable via GET,
> because there are a lot more agents in the wild that support GET than
> MGET.
>
> However I agree that some sort of extension is needed to allow clients
> to obtain metadata about a resource, so I was thinking about how MGET
> could be made more GET-friendly, so that the metadata is really part
> of the web.
>
>
> How about if it was MANDATORY for responses to MGET to have a
> Content-Location header giving a URL which could be used to retrieve
> the metadata via GET.

Please see the FAQ section of the URIQA spec 
(http://sw.nokia.com/uriqa/URIQA.html)
which addresses this and other alternative methods, and why they don't
work, or are less optimal than the present definition of URIQA.

>
> In practise the URIQA implementation provides GET'able URIs for the
> metadata anyway, and I imagine that this would be a fairly common
> technique to ensure compatibility with browsers so it should be cheap
> to implement.
>
> Ensuring GET access to MGET content has a number of advantages.
>
> It wouldn't solve the problem of how to discover metadata for legacy
> clients, but it would allow clients incapable of performing MGET
> requests to still be able to access and process metadata if the URL
> for it is discovered on the client's behalf by an MGET-enabled client.

Then why couldn't that intermediary simply provide the description?

Also, any *client* that can execute a GET and consume RDF/XML in
the response can also execute an MGET and consume the RDF/XML
description.

(granted, there are some issues with some SDKs which hobble
clients to not be able to execute arbitrary requests, but that's
a problem with those SDKs, not with the URIQA design)

>
> It allows dual-implementations of metadata discovery, eg a webpage
> could support MGET, and use one of the other methods such as a <link>
> tag.
>
> It also makes it possible to obtain meta-metadata by performing an
> MGET on the URL given as the Content-Location. In this scenario,
> perhaps an MHEAD method would be useful?

I have no problem with URIQA proxies, serving clients via GET/POST.

Though this seems to me to be a matter of implementational preference,
rather than something pertaining to the design of URIQA in general
(or have I missed something?)

Cheers,

Patrick

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Wednesday, 10 March 2004 05:03:19 UTC