When a feed aggregator creates a feed from different sources
(feeds) with different licenses, what should be the license of the
resulting feed? <<
Very important point Karl! Thanks for bringing it to the surface :)
>> Defining the semantics of the attribute/element is cool, but on the
side in the implementation it's not clear what should be by consuming
products. As I said in a previous message, it's a tough problem. <<
It *seems* that the category element with @scheme, @label, @term could act particullary well in regards to allowing for a human readable definition, a human/machine readable label, and a human but more importantly machine readable scheme that could represent the "rules" definition file in which could be parsed and used as the pass/fail method to determine which license both can apply as well as which one best applies to the situation.
What I mean by this is that if there were three category elements in which each contained @lable="license" [1], if a best practices doc suggested ordering them from most confining to least (using a 100% commercial use > 100% non-commercial (or would that need to be the other way around to make proper sense?) use pattern for ordering the category elements), then as soon as they reached the point in which they passed all rules for a given scheme, the machine could them stop processing schemes and move forward with the rest of the processing based on the set of rules set forth in the current "in-process" scheme. T
his, of course, would suggest that the best way to build out the scheme file would be to start with the pass/fail "questions" to then follow with what can and can not be used as part of the final output. Obviously from a machine standpoint this would allow for the most efficient usage of XML as there would be no need to climb up and down the tree looking for the next set of processing rules once a 100% pass level has been reached. This would allow for forward only readers to be implemented, and would obviously work well with the streaming SAX+ implementations.
Of course this leads nicely into...
>> 2. Should there be a best practices document to invite tools
developers to understand and implement licenses mechanism? (As I
understand it's not the purpose of this draft). <<
Yes please! :D
On 6/9/06, Karl Dubost <[EMAIL PROTECTED]> wrote:
Reading the example from
http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/
[[[
3. The 'license' link relation
An Atom link element with a 'rel' attribute value of 'license' is
used to associate a copyright license with an Atom Feed or Entry.
Atom entry, feed and source elements MAY each contain any number of
license links but MUST NOT contain more than one with the same href
value. The IRI specified by the link's 'href' attribute SHOULD be
dereferenceable to return a machine or human-readable representation
of the license.
Implementors should note that, unlike the Atom rights element, which
specifies a human-readable statement of the rights held over a entry
or feed, license links apply only to the informational content of
the
containing element. That is, the presence of a license link
relation
within an Atom feed element does not extend a license over the
various contained entry elements. Likewise, the presence of a
license link within an Atom source element does not extend a license
over the informational content of the containing entry.
]]]
-- snell-atompub-feed-license-06.txt
http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/
#page-3
Thu, 13 Apr 2006 19:27:54 GMT
# Some questions about specific use cases
1. Feed composed with multiple sources with different licenses.
When a feed aggregator creates a feed from different sources
(feeds) with different licenses, what should be the license of the
resulting feed?
feed (license ???)
entry (license A) from feed X
entry (license B) from feed Y
entry (license B) from feed Y
entry (license A) from feed X
entry (license C) from feed Z
…
Defining the semantics of the attribute/element is cool, but on the
side in the implementation it's not clear what should be by consuming
products. As I said in a previous message, it's a tough problem.
2. Should there be a best practices document to invite tools
developers to understand and implement licenses mechanism? (As I
understand it's not the purpose of this draft).
--
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
QA Weblog - http://www.w3.org/QA/
*** Be Strict To Be Cool ***
--
<M:D/>
M. David Peterson
http://www.xsltblog.com/
