On 12/17/06, David Powell <[EMAIL PROTECTED]> wrote:
What you can do however, is to specify that feed licenses apply to the "feed", and inherit to the entries in the feed. ... It means that the license applies to all entries in that feed, not just ones in that specific feed document. This is probably reasonable behaviour for licenses anyway.
Particularly in the case of licenses, it is very important to distinguish between the "feed" or stream of all entries (past, present and future) associated with a feed id and the actual feed documents that encapsulate subsets of that stream. Atom provides no mechanism for associating meta-data with "feeds." Atom only supports associating meta-data with Feed Documents. Data in one feed document does not apply to entries found in another feed document -- or to entries that stand-alone. Feed meta-data found in one feed document does not override, compliment or invalidate feed meta-data found in other feed documents. This is one of the many reasons we have atom:source -- so that we can bind specific feed meta-data to an entry no matter what context in which that entry might appear or when it might be read. If we had a case where data in one feed document overrides data in other feed documents, we'd have a mess. Some of the questions that we'd have to answer are: - Elements like atom:author, atom:contributor and atom:rights can and do change over time -- sometimes frequently. If such a change occurs, does it mean that we've implied a change to all previous entries published in all previously published feed documents? This rule would tend to force us to create new feeds (i.e. new feed ids) whenever authors, contributors, or rights change. This would make a mess for aggregators and feed readers who have enough trouble keeping up with changes in the syndisphere... - If data is present in one feed doc but not another later document, does the absence of the data in the later document override the previous document or do we combine what we know from both documents? (i.e. if the earlier Feed document had an atom:contributor field but a later Feed Document does not, does this mean that we wipe out knowledge of the contributor who might have been essential to creating some of the earlier entries? (That's kind of heartless -- it would be a high tech version of "What have you done for me lately?...") Or, do we improperly maintain the old contributor as a contributor of new entries --potentially long after the contributor has died?) - How do we handle mistakes? For instance, if after publishing several thousand feed documents in sequence, I might publish one that accidentally grants "all rights to everyone" when I really meant to grant only "non-commercial" rights. Does the new badly coded feed document force all of the thousands of entries I've been working on over time into the public domain even if that wasn't what I intended? - How do I "repair" the mistake discussed immediately above? If I publish a new feed document with a license grant for "non-commercial use," does that then apply to all previously published entries -- including those that were accidentally published with over-generous rights? Does this mean that I can use a license in one feed document to *restrict* or rescind rights granted by another feed document? (This would be a very bad thing...) - If I have an aggregator that picks up some content which is licensed for general use today, how can I be sure that I can still use the content tomorrow? If the content of a Feed Document applies retroactively, it would seem that I have to re-fetch the feed every time I use content from the feed so that I can check the metadata. This doesn't seem to make sense. If I were sued by someone, could I use the argument: "But, I didn't read the new, more restrictive Feed Documents!" Is ignorance an excuse? I could go on...But, I hope the case is made. Feed Documents only describe themselves and the entries they contain. They do not "describe" the feed.
if you store a feed in an implementation such as Microsoft's Feed Engine, only a single set of feed extensions will be associated with the feed.
While it is important to be aware of the inadequacies (as well as the strengths) of implementations by companies with significant market power, I don't think that we can simply delegate the standards writing process to such companies or modify standards to cover up their bugs. The fact that Microsoft or any other company has done the wrong thing should not, in itself, be sufficient to dictate the development of standards. Hopefully, they will eventually see the error in their ways and correct them. bob wyman
