A significant part of my brain is screaming at me that the most logical
way to associate a license with an entry/feed is to use a link element.
After all, we are linking the entry/feed with an external resource (the
license) that is identifiable via URI. For instance, if I ommitted the
various permits and requires elements, the following would look very
natural and straight forward:
<feed xmlns="http://www.w3.org/2005/Atom";>
...
<link rel="license"
href="http://www.creativecommons.org/licenses/example1"; />
</feed>
It seems that it's only when I introduce the subelements to link that
things start to appear ugly.
<feed xmlns="http://www.w3.org/2005/Atom";>
...
<link rel="license"
href="http://www.creativecommons.org/licenses/example1"; xmlns:lic="...">
<lic:permits />
<lic:requires />
</link>
</feed>
At the same time, it is entirely possible for us to make the above link
compatible with the existing RDF creative commons license by using:
<link rel="license"
href="http://www.creativecommons.org/licenses/example1";
rdf:resource="http://www.creativecommons.org/licenses/example1";
rdf:type="http://web.resource.org/cc/license";
xmlns:lic="http://web.resource.org/cc/";>
<lic:permits rdf:resource="..." />
<lic:requires rdf:resource="..." />
</link>
The bottom line to this is that it is possible for us to create a
link-based license attachment for Atom that is backwards compatible with
the RDF-based Creative Commons module for RSS 1.0. Now, I will say that
using a specific license element looks nicer (e.g. <license><permits
/><requires /></license>, etc) but the use of link just seems far too
logical for it not to be used in this way.
I've implemented a prototype of this in my personal blogs Atom 1.0
feed. Unfortunately the Feed Validator does not yet recognize extension
attributes and elements in link elements as being valid.
http://www.snellspace.com/wp/wp-atom1.php
- James
A. Pagaltzis wrote:
* David Powell <[EMAIL PROTECTED]> [2005-07-13 08:45]:
Because the content of atom:link is undefined, there is a risk
that some implementations, particularly Atom server
implementations accepting entries from a publishing client,
might just drop the contents of the element.
We had a discussion recently about this very aspect of the spec,
which concluded that there is no reason that extension elements
would be disallowed inside atom:link. So per the spec, consumers
should expect that extension elements may appear inside
atom:link.
I do agree that a Simple Extension Element (or several) would be
the logical choice for this particular use case, as they offer
defined semantics for attaching metadata directly to an entry.
Regards,
