James M Snell wrote:
<category scheme="http://example.org/restriction/country/allow"; term="au us" /> <category scheme="http://example.org/restriction/country/deny"; term="ca fr" />+1. it felt odd when I typed it also; but this is a strawman and needs to be kicked around a bit. Are these really going to be necessary, anyway?
Well either those values are informative (don't bother trying to download this link if you're in France since it's not going to work); or they're meant to be a cheap form of DRM (you MUST NOT download this link if you're from France or the RIAA will try and have you arrested).
In the former case the values can't be trusted (and the client probably won't know where it is anyway), so it's easiest to just download the link anyway and see what works. The latter case is unenforceable so it's pointless. So unless I'm missing something, I don't see the need.
It is dereferencable... just not in the way most implementations would likely expect. :-)
RFC3986: "When a same-document reference is dereferenced for a retrieval action [...] a dereference should not result in a new retrieval action."
So what exactly does one do with such a link? How do you get back a quick-time video from that feed without performing a new retrieval action? I may be missing something but I don't think that's defined. If it's going to break existing implementations that aren't doing anything wrong, then I think you should avoid it.
Anyway, the main point is that given a set of links with a given rel (e.g. "enclosure") how do we identify which is the "primary" or "default" representation?
I understand the intention - I just think you need to come up with another way of doing that.
Heh... ok. As a client developer, what metadata might be useful to you? :-)
None actually. But I don't do anything fancy with enclosures. All I really need is a well-written title attribute, so if I display a list of enclosures to the user, they can make an informed decision about which ones they might want to download.
If I *was* doing something fancy with enclosures (like some kind of download manager), there are probably a number of things I might find useful, but stuff like sampling rate and color depth would not be on that list.
Now I'm sure there are other use-cases that might benefit from other metadata, but you really need to find people that actually intend to do something with this stuff before you try and lock down what it will be. So far the only concrete use-case I've heard here was for some form of proprietary data exchange, and frankly you might as well use a proprietary extension for that (actually I don't even see the point of using Atom for that).
Regards James
