Re: Inheritance of license grants by entries in a feed
On 1/14/07, David Powell <[EMAIL PROTECTED]> wrote:> 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. Inheritance can't be "incompatible" with Atom since Atom defines it. I do agree with you, however, if you argue that Atom would have been cleaner without inheritance. Without inheritance, feed level meta-data would only apply to the "collection" which contains entries and not to the entries themselves. Without inheritance, we wouldn't need atom:source -- we would have only needed atom:provenance (a simple link to an entry's origin feed similar to the source element in RSS. Note: Synthetic feed producers still would have wanted atom:source as a convenient way to reduce the need to repeatedly fetch feed documents to get atom:title values.) However, folk really wanted to keep inheritance of the feed metadata and so we ended up having to define something more complex. bob wyman
Re: Inheritance of license grants by entries in a feed
On 1/14/07, David Powell <[EMAIL PROTECTED]> wrote:>Atom doesn't describe the processing model of Atom documents explicitly enough for me to infer much about the semantics of atom:source. ... Needing to [use atom:source] is a good sign that you are abusing feed elements to carry entry metadata though. There are quite a few very common, non-abusive reasons for using atom:source. For instance, the RFC clearly discusses the case where an entry is copied from one feed document into another and needs to maintain its association with the feed metadata of the source feed. There is also the question of signatures In any case, I read the Atom spec as clearly intending that an entry with an atom:source element can be semantically equivalent to a single entry feed document whose feed meta-data is equivelant to that contained in the entry's atom:source. If this isn't what appears to be written, then I suggest that it is a case of non-optimal drafting and the history of this group should be consulted to clarify the intent. I explained why entries with source needed to be equivelant to single entry feeds when I made the original proposal for atom:source at the first Atom community meeting at Sun in June of 2004 and I made it continuously throughout the process of drafting the RFC. This is also one of the many reasons why Atom "assigns no significance to the order of atom:entry elements within the feed." The meaning of an entry derives only from data which is either encoded within it or which is recorded as part of the feed metadata associated with the entry. That association is either by containment within a feed document or, more strongly, by encapsulating the feed metadata within the entry. This equivelance property is essential in order to make aggregated/synthetic feeds work and it is necessary to make licensing work properly. (Yes, there were some of us thinking about licensing long before James made his proposal...) Thus, the "processing model" for an entry with an atom:source is just as precisely described as the processing model for a single entry feed document... bob wyman
Atom license extension - final stages
All, The Atom license extension is continuing to move forward. Based on some last call comments that were received, I have decided to add two additional items to the spec: 1. An equivalence rule for license URIs 2. A IANA registry for common license URIs Over the next week I'll be working up the details of each and will be posting a new draft, likely by next Friday. - James
Re: Inheritance of license grants by entries in a feed
On 1/14/07, David Powell <[EMAIL PROTECTED]> wrote:> 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. An implementation should only do things based on the license extension if it understands what the license extension means. Since the draft now has carefully written words to ensure that license extensions only grant additional rights and do not restrict default rights, the worst case situation is that an implementation that doesn't understand the license extension inheritance will simply treat entries as though they only had normal, copyright-defined rights associated with them. i.e. You would get fair use, implied right to syndicate, right to read, right to make facilitative copies, etc. but you wouldn't realize that you also get whatever extra rights were granted by the license. This is, I think a reasonable fall-back. Of course, implementations that do understand that feed-level licenses are inherited will be able to manage rights just a bit better. This is a good thing. A failure to properly implement license inheritance tends to limit what the *reader* believes they can do with entries, but it doesn't do any "harm" to the owner of the intellectual property in the entries since no one can believe that they have rights not granted. The worst that can happen is that readers don't know all the rights they have. This is acceptable, in my opinion. bob wyman
Re: Inheritance of license grants by entries in a feed
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 and 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 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 >
