Sorry for the delay in responding. I disagree that feed elements apply to the feed document and not the feed itself. I believe that both the spirit and letter of the specification make it clear that feed elements are metadata about the feed not the document, and the typical behaviour of implementations seems to agree.
I agree that it is important to distinguish between feeds and feed documents, and this is why I think that feed level inheritance of licenses should be dropped as it is incompatible with Atom. Monday, December 18, 2006, 10:22:17 PM, Bob Wyman wrote: > 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." The text of RFC4287 seems to contradict this: The "atom:feed" element is the document (i.e., top-level) element of an Atom Feed Document, acting as a container for metadata and data associated with the feed. Atom does support inheritance of <author> and <rights> elements, but only because this is behaviour is clearly documented in the core specification, so there can be no doubt of how implementations should process these elements: If an atom:entry element does not contain atom:author elements, then the atom:author elements of the contained atom:source element are considered to apply. In an Atom Feed Document, the atom:author elements of the containing atom:feed element are considered to apply to the entry if there are no atom:author elements in the locations described above. Effectively, this inheritance can be implemented by copying the elements at the feed document parsing stage. You can't just say that the license extension inherits and expect every implementation out there to implement that. You'd need an Atom 2.0 to do that: either support for must-understand (which was rejected from Atom 1.0), or a special feed document extension container. I agree that feed document inheritance would be a useful feature, but as we don't have it we'll have to write out these duplicate elements longhand. It isn't such a big deal though. It also seems obvious to me that feed elements are metadata applied to the feed based on the expected behaviour of implementations. As an example: I observed a feed that I am subscribed to in Bloglines change its feed title in the feed list pane. The feed did this by changing the value of the <title> element for the feed. Surely you wouldn't say that no conclusion can be drawn from this change in feed document as to the intended change in state of the feed? The whole feed model is based around changing feed documents communicating the latest state of the feed; for both the entries in the feed and the feed itself. In fact the whole web is based around the fact that representations of resources can vary over time, and that the latest representation is, the latest. > 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. If you poll a feed twice you have two feed documents. These are obviously related. If I update an entry element, then the latter version is understood to be a replacement. You can correlate them by the entry ids and updated. If I update a feed element, then the latter version is understood to be the replacement. What's the problem? I don't see how it could work any other way. > 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. Atom doesn't describe the processing model of Atom documents explicitly enough for me to infer much about the semantics of atom:source. If you want each entry (or a group of entries within a document) to have its own private feed state, then atom:source is one way to implement that. Needing to do that is a good sign that you are abusing feed elements to carry entry metadata though. > 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? RFC4287 is clear about the semantics of these elements. They apply to the feed, and are also inherited to the entries. They can do that because that behaviour is prescribed in the RFC; we can't do that for license extensions because it is not. The authorship of the feed applies to the feed in general. The authors of boingboing might be Mark, Cory, David, Xeni, and John. That doesn't mean that these have to be updated dynamically depending on who the actual authors of each of the 10 entries in the feed are at that instant. Admittedly the behaviour of these "inheriting" elements, and the interactions between their applicability to the feed and to the entries is a bit odd. I don't like it much. > (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?) If you want the contributor to apply specifically to entries that the contributor wrote, then put it on the entry. If you just want to describe general current contributor-ship then put it on the feed. > + 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? The former. Its the same with feeds as it is with entries. > + 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? If you post a message on your website that says that all of your website is in the public domain, by mistake, does that force all of your website into the public domain. I don't know, I'm not lawyer. > + 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? Yes. > 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...) Yes, documents on the Internet aren't immutable. I don't see how this is surprising. > + 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? The whole web works this way. Here is a link: http://www.apple.com/legal/terms/site.html How can you know that these terms and conditions haven't changed once you've read them? You can't. >> 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. I believe that that implementation is behaving correctly. It follows the RFC and it is no different that other feed readers I've seen. -- Dave
