On Jan 17, 6:09 am, Nils <[email protected]> wrote: > In my opinion Metalinks are a representation of the actual resource > BECAUSE they are a description of something that actually exists, and > are not merely a link/pointer/reference. > Hence TCN is correctly used here. > And hence there is no problem at all.
This is a bit of a contradiction. Something cannot be a representation of a resource and a description of it at the same time. But of course people can (and have) stretched the meaning of 'representation' to be, well, pretty much anything. > And I think a philosophical discussion of "representation vs. > description vs. complete view" in general and of the intension the > authors of 1997 and 1998 RFCs had in particular is non-sense. I am not sure how 1997/8 are related to this. > There is a valid point for Link:, e.g. for referencing previous > chapters of a document or telling the client "hey, I have an > alternative representation here you didn't think of requesting > yourself you might still be interested in", i.e when you actually want > to reference/point another resource. Link defines a relationship between any two resources. "My Metalink description" is a valid relationship. > When it comes to metalink TCN, the client explicitly has to ask the > server for this representation, and hence there is no problem for non- > metalink clients receiving the fairly degraded (to them at least) > metalink view. > (Maybe this should be clarified in the Metalink spec, especially that > servers should assign a pretty low q=-value to metalink > representations of a resource to avoid sending out metalinks to non- > metalink clients). Again, there is nothing 'technically' wrong with this approach any others have taken a similar position that a descriptor can be collapsed into a single resource URI. But a consensus is building that this is the wrong way of doing things. What you might want to consider, since you find the semantic discussion as nonsense (which I can respect) is the deployment ramifications of using the Accept header. Many platforms limit access to such headers, some proxies mishandle Vary headers (which BTW, the spec should require with to any Accept reply), and some providers will not allow using it on their servers. You might want to read John Panzer's view of this [1]. You can also support both approaches, allowing providers to accept the Accept header, but also declare the availability of metalink using the Link header. Dumb clients can then do a HEAD on the URI if they cannot use Accpet. EHL [1] http://www.abstractioneer.org/2008/11/discovery-metadata-is-just-data.html --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
