In taking a look back over the archives, I see that a good bit or
discussion around links & link extension has already place [0], which I
found enlightening (and I am happy to back away from rehashing old
arguments if that all this ends up being).
In the interest of putting the "what" before the "how", the goals here, as
I understand it, would be to figure out a way to:
1. provide a way to add metadata to a particular atom:link
2. provide a way to group a set of links and/or to establish a
relationship between links that appear in a single atom:entry and possibly
to "type" those relationships
and the means at our disposal:
1. the "rel" attribute of atom:link
2. new extension attributes of atom:link
3. child elements of atom link (and attributes on those elements).
By sticking to those goals & means, I suspect you cover most use cases (at
least ones that have at hand and/or am aware of), AND clients that DON'T
implement such an extension shouldn't be hampered.
The one bit of "how" I'd like to see (and this, I realize, may not be a
majority opinion) would be to have every media entity have it's own
atom:link, and not be made a child of another atom:link or made part of an
enumerated, space-delimited list in an atom:link attribute. I.e., I would
hope that the relationships/groups could be expressed as metadata "about"
a link. (The challenge, of course, is to figure out a way to say "this is
related to that" without identifying the "that" in the statement). James
Snell's Atom Link Extension ID used a "group" attribute on atom:link with
a case-insensitive opaque text string identifying the group. One would
them need to rely on the type or rel attributes to discover the media
entities "role" in that group. Not bad, I think.
Grouping/relationships is the trickiest bit. Not as difficult, would be to
come up with the list of metadata attributes that might be used with a
link and figure out if they should be attributes on atom:link or children.
If children (my preference), you could keep them fairly abstract and allow
for an "open" set of possible values, e.g.:
<link ...>
<x:hash type="md5">391ea33cbe3a052e6b247c7b943d1a73</hash>
</link>
OR even:
<link ....>
<x:format type="height" unit="px">128</format>
<x:format type="channelMode">stereo</format>
</link>
--Peter Keane
[0] http://www.imc.org/atom-syntax/mail-archive/msg17378.html
On Fri, 18 Jan 2008, James Holderness wrote:
Eric Scheid wrote:
On 18/1/08 3:20 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
One of the criticisms of that work was that while rfc4287 allowed the
atom:link element to have child elements, it was not clear how many
implementations would actually be able to do anything with them. Another
issue was whether implementations that could get to the extensions
actually would do anything with them.
that is pretty much par for the course for *any* extension though, right?
Sure, but if you can't find anyone that intends to use your extension (and
you need both clients and servers), you have to ask yourself why you're
bothering to design it in the first place.
Not that I'm saying that's the case for media extensions. I just don't think
you should underestimate the importance of the question: will anyone use
this?
Regards
James
