The TAG has not officially ruled on this but individual members have expressed the view that this is not consistent with HTTP. This came up most recently in their review of Yadis, the discovery protocol used by OpenID which uses the Accept header to request the descriptor instead of the resource. There is no easy answer whether this is allowed or not.
One way to look at this is as views of the same resource. If there was one representation that is complete (i.e. contains both the file being downloaded and its metalink information), you can argue that a metalink-only view is valid, as well as the file itself. But without such unifying view, it is hard to claim that these are two representations of the same resource. One is the resource, the other is 'about' it. This gets philosophical very quickly... I have been reviewing this for the past few months for XRD, another descriptor format (POWDER is yet another). My use case is more complex than metalink because sometimes there is no resource, just metadata (abstract resources). I have a few other requirements which led me to write my discovery spec [2]. However, in the case of metalink, I think the Link header should be enough for you needs since there is always an HTTP URI you can perform GET on to find the Link header [1]. The downside is that it adds an extra round trip (one for the header, another for the metalink document). There is no easy way around it unless you are willing to use HTTP OPTIONS, etc. I wrote a blog post [3] about this which is included in my draft. One thing sites with a lot of downloads can do is use the Site-Meta options in my discovery draft to declare a URI which can be used to request the metalink document for other resource URIs. But again, I think it would be enough for metalink to simply use the Link header [1]. Let me know if I can help in any way. EHL [1] http://tools.ietf.org/html/draft-nottingham-http-link-header-03 [2] http://tools.ietf.org/html/draft-hammer-discovery-01 [3] http://www.hueniverse.com/hueniverse/2008/09/discovery-and-h.html On Jan 16, 4:13 pm, Anthony Bryan <[email protected]> wrote: > Eran Hammer-Lahav and Mark Nottingham have informed me that using > transparent content negotiation for serving a "description" of a file, > and not an alternative version (like PNG vs JPG) of the same thing has > been ruled against by the W3C TAG. > seehttp://esw.w3.org/topic/FindingResourceDescriptions > > "Other ways of getting a description through HTTP > * Use content negotiation. If you ask for RDF, you get the > description. If you ask for something else, you get the thing > described. (The TAG, TimBL, and others have pointed out that this > contradicts web architecture, which requires that content negotiation > choose among things that all carry the same information. That goes for > CN between RDF and HTML as much as it does for CN between GIF and > JPEG.)" > > the correct, web architecture complient way to do this is apparently > the HTTP Link header: > > Link: <http://example.com/resource.metalink>; rel="describedby"; > type="application/metalink+xml"; > > http://tools.ietf.org/html/draft-nottingham-http-link-header-03http://tools.ietf.org/html/draft-hammer-discovery-01 > > -- > (( Anthony Bryan ... Metalink [http://www.metalinker.org] > )) Easier, More Reliable, Self Healing Downloads --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Metalink Discussion" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/metalink-discussion?hl=en -~----------~----~----~----~------~----~------~--~---
