James M Snell wrote:
Mike Linksvayer wrote:
On Tue, 2006-09-05 at 15:53 -0700, James M Snell wrote:
Mike Linksvayer wrote:
In any case, the draft says the referenced license only applies to feed
or entry metadata, not content. This strikes me as not particularly
useful and does not match analogous extentions for RSS 1.0 and RSS 2.0:
The difference in semantics is precisely why I'm not using either the
RSS 1.0 or RSS 2.0 extensions for this as I see problems with both the
former approaches.
I understand having problems with RSS 1.0 and RSS 2.0 approaches but I
don't see an inherent and important difference in semantics,
particularly between Atom 1.0 and RSS 2.0. Of course my vision is
probably foggy. :)
The difference boils down to one very simple point: contained resources
do not necessarily inherit the license of the container. The RSS 1.0
and RSS 2.0 modules both assume that the rights holder of the channel
also holds rights over all of the contained items, which works fine when
I'm publishing my own blogs entries in my own feed, but breaks down when
I'm republishing entries from multiple sources.
Here's my rationale: Atom has explicit support in the core RFC 4287
syntax for 'synthetic' feeds containing entries from multiple sources
produced by multiple authors with different copyrights. RSS 2.0
doesn't have this core support. So in the case of Atom, the issue is a
bit more urgent. So tackling the Atom case first makes sense to me.
(Aside: Is there any reason why an Atom extension couldn't also be used
as an RSS 2.0 extension too? In this case, there would be a valid
reason to add to the already crowded space of license extensions:
Because it lets you specify the feed license terms separately from the
individual entry license terms, whereas the other RSS licensing schemes
don't.)
[snip]
(I'm still stewing over the bit of comments that I snipped out of this
:-) ...)
I agree that assuming entries inherit licenses specified at a feed level
is problematic. My concern, at the feed and entry level, is that the
atom license extension draft says that a link relation can (only) be
used to associate a license with feed or entry metadata, rather than
content. Unlike other children of <feed> and <entry> the license
extension is not metadata for the feed or entry but metametadata for the
feed or entry metadata, which strikes me as not particularly useful and
contrary to both RSS 1.0 and RSS 2.0 modules, whatever differences exist
between those.
My apologies if I haven't been clear on this. If you look again at
section 1.3, you should find the following:
For entry elements, "metadata" refers to the values and attributes of
the author, category, content, contributor, id, link, published,
rights, source, summary, title, and updated elements, as well as all
extension elements appearing as children of the entry element and all
elements appearing as children of the author and contributor
elements.
Note that the value and attributes of the content, summary, title, etc
elements are all included in entry "metadata". What isn't covered are
any linked resources. So any content actually appearing within the
entry is covered by the entry license.
(Is it just me, or is there too much overloading of "metadata" here?)
Also, does this mean that an entry license would apply to this content:
<content
type="image/gif">TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG</content>
but not to the same content communicated through an indirect link?
<content type="image/gif"
src="" class="moz-txt-link-rfc2396E" href="http://example.org/catpicture001.gif">"http://example.org/catpicture001.gif"/>
(I'm deliberately picking a GIF picture as I believe there's no good
solution for embedding license metadata inside GIFs. )
-John Panzer
|
