Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
James M Snell wrote: Bob Wyman wrote: Aristotle Pagaltzis wrote: That issue is inheritance. Let me give an example of problematic inheritance... Some have suggested that there be a License that you can associate with Atom feeds and entries. However, scoping becomes very important in this case because of some peculiarities of the legal system. One can copyright an individual thing and one can copyright a collection of things. A claim of copyright in a collection is not, however, necessarily a claim of copyright over the elements of the collection. Similarly, a claim of copyright over an element of the collection doesn't reduce any claim of copyright in the collection itself. If we assume inheritance from feed elements, then without further specification, it isn't possible to claim copyright in the collection that is the feed without claiming copyright in its individual parts. What you'd have to do is create two distinct types of claim (one for collection and one for item. That's messy.) I'm sure that copyright and licenses aren't the only problematic contexts here. bob wyman From the format text: 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. This really does not describe an inheritance model*. This describes a scoping model. If an entry does not contain an author, the author on the feed is said to apply. scope v inheritance: call what you like, it's still undefined. 1. We didn't do that, I imagine because it was 'simpler' to say nothing than introduce formalism. The only person that has tried to formally define the relationship is Henry afaik. Unless we have defined clearly the semantics of the relationship between a feed and a entry*, we're hosed if we start trying to figure out the logical implications of domain and range of metadata - whatever we conclude, unless it gets baked into a spec as a patch, somebody with running code will be sure to conclude otherwise. Coincidentally I posted a rant about this kind of specification on xml-dev the other day mentioning feed/entry. 2. It's easy to be tricked by the document structure into thinking there is some form of natural scoping mechanism. If Atom looked like this atom:feed atom:feed-metadata-container atom:entries-container atom:entry or atom:feed atom:entries-container atom:[EMAIL PROTECTED]'feed-metadata' atom:entry We probably wouldn't be having this discussion. Second note to self: After thinking about this a bit more, I would also need a way of specifying a null license (e.g. the lack of a license). For instance, what if an entry that does not contain a license is aggregated into a feed that has a license. The original lack-of-license still applies to that entry regardless of what is specified on the feed level. Golly Bob, you're right, this is rather messy ain't it. Hmm... This is not new ground for the WG. We've been through it and my understanding is that feed level metadata does not inherit/cascade/scope over entries. I seem to recall thinking that atom:author percolating down from the feed is essentially broken, but the consensus was it should do that. It's an exception, not a precedent. As we have no processing model for this, my answer to Paul's question is that feed level extensions do not inherit/cascade/scope over entry level ones, irrespective of whether they're foreign or not, and that the best way to think about atom:author is as a frozen accident. [I hope the folks working on the APP are paying attention.] cheers Bill * Tangentially touched upon here: http://www.dehora.net/journal/2004/06/atomrss_relating_entries_and_feeds.html.
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
Bill de hÓra wrote: As we have no processing model for this, my answer to Paul's question is that feed level extensions do not inherit/cascade/scope over entry level ones, irrespective of whether they're foreign or not, and that the best way to think about atom:author is as a frozen accident. Ok, this is absolutely fine. I'll go back through and update my various extension proposals to reflect this train of thought. - James
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
On 22 Aug 2005, at 18:29, James M Snell wrote: Bill de hÓra wrote: As we have no processing model for this, my answer to Paul's question is that feed level extensions do not inherit/cascade/scope over entry level ones, irrespective of whether they're foreign or not, and that the best way to think about atom:author is as a frozen accident. +1 Ok, this is absolutely fine. I'll go back through and update my various extension proposals to reflect this train of thought. - James
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
Bob Wyman [EMAIL PROTECTED] wrote: Paul Hoffman asked: Does an informative extension that appears at the feed level (as compared to in entries) indicate: a) this information pertains to each entry b) this information pertains to the feed itself c) this information pertains to each entry and to the feed itself d) completely unknown unless specified in the extension definition I believe the correct answer is e: e) Unless otherwise specified, this information pertains to the feed only. I agree. Once you've accepted that there's a difference between the feed itself and the set of all past, present and future articles in the feed (which there certainly is in the general case) then you really have to accept e) as the only possibility for unknown metadata in the feed head section. Regards, Peter -- Peter Robinson http://www.ticketswitch.com/
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
On Aug 21, 2005, at 1:42 PM, A. Pagaltzis wrote: * Paul Hoffman [EMAIL PROTECTED] [2005-08-21 21:55]: Ah, I had missed that. This leads to a question for the mailing list. Does an informative extension that appears at the feed level (as compared to in entries) indicate: d) completely unknown unless specified in the extension definition Atom itself has precedent for both b) and c). So I would say it’s d) – but also that aggregators should assume b) when they don’t know any better. Right, the only possible answer. -Tim
RE: Extensions at the feed level (Was: Re: geolocation in atom:author?)
James M Snell wrote: Second note to self: After thinking about this a bit more, I would also need a way of specifying a null license (e.g. the lack of a license). For instance, what if an entry that does not contain a license is aggregated into a feed that has a license. The original lack-of-license still applies to that entry regardless of what is specified on the feed level. Golly Bob, you're right, this is rather messy ain't it. Hmm... My apologies for not having more clearly pointed this out in my original message. The problem is exacerbated for folk like us at PubSub since we would feel completely comfortable in claiming copyright over the collection of entries that we pass along to our subscribers, however, there is *no way* that we could even hint at claiming copyright over the individual entries themselves. If statements made at the feed level are inherited by or in the scope of the entries, then we would not be able to assert a copyright claim at the feed level since it would leak down to the entries. Of course, one might argue that since we at PubSub will virtually always ensure that any entry we publish has an atom:source element, one could argue that we don't have to worry about this scope leakage. But, we're a special case in this regard. The general issue of scope exists in cases where the atom:source element is not present. bob wyman
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
On 8/22/05, Bill de hÓra [EMAIL PROTECTED] wrote: As we have no processing model for this, my answer to Paul's question is that feed level extensions do not inherit/cascade/scope over entry level ones, irrespective of whether they're foreign or not, and that the best way to think about atom:author is as a frozen accident. I always assumed (and objected, mildly) that the atom:author stuff was the WG's way of saying you had better write something similar to this code, which I spotted in the wild (ooh, what's this? A rarely seen RDF parser... sshh): item.author = getRDFTargetValue(ds, itemResource, DC_CREATOR) || getRDFTargetValue(ds, channel, DC_CREATOR) || theFeed.title || item.author; I didn't really agree that we should say anything about it, but most other folks did, and I see it more as a fact of life than something that could be cleared up with a formal model. There will always be some new extension getting wedged in the search sequence. Which reminds me, I should write a patch for iTunesRSS. Robert Sayre
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
Sunday, August 21, 2005, 8:46:54 PM, Paul Hoffman wrote: At 7:24 PM +0100 8/21/05, Peter Robinson wrote: I do something similar, intending it to mean the location of the items described by this feed (when there is a single location). Ah, I had missed that. This leads to a question for the mailing list. Does an informative extension that appears at the feed level (as compared to in entries) indicate: a) this information pertains to each entry b) this information pertains to the feed itself c) this information pertains to each entry and to the feed itself d) completely unknown unless specified in the extension definition In my RDF model, feed extensions (together with properties such as atom:generator), are considered to be properties of the FeedInstance. EntryInstance's are related to FeedInstance's using containingFeed and sourceFeed properties. (Entry's and Feed's can have multiple EntryInstance's and FeedInstance's, but that's not really relevant...) So, feed extensions don't automatically inherit to entries in the model (unlike atom:author which does), but for a given entry you can locate its feed and take a look at its extension properties, so it isn't like the information is lost. So I'd say b); but as long as you aren't throwing away atom:feed data, that shouldn't prevent an application using feed extensions to do a) or c). I think that the interpretation b) is probably what is supported by section 6 in the absence of any talk about extension inheritance. -- Dave
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
* Paul Hoffman [EMAIL PROTECTED] [2005-08-21 21:55]: Ah, I had missed that. This leads to a question for the mailing list. Does an informative extension that appears at the feed level (as compared to in entries) indicate: a) this information pertains to each entry b) this information pertains to the feed itself c) this information pertains to each entry and to the feed itself d) completely unknown unless specified in the extension definition Atom itself has precedent for both b) and c). So I would say it’s d) – but also that aggregators should assume b) when they don’t know any better. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
RE: Extensions at the feed level (Was: Re: geolocation in atom:author?)
Paul Hoffman asked: Does an informative extension that appears at the feed level (as compared to in entries) indicate: a) this information pertains to each entry b) this information pertains to the feed itself c) this information pertains to each entry and to the feed itself d) completely unknown unless specified in the extension definition I believe the correct answer is e: e) Unless otherwise specified, this information pertains to the feed only. bob wyman
RE: Extensions at the feed level (Was: Re: geolocation in atom:author?)
At 5:10 PM -0400 8/21/05, Bob Wyman wrote: I believe the correct answer is e: e) Unless otherwise specified, this information pertains to the feed only. Er, right. Change that list to: a) this information pertains to each entry (unless otherwise specified) b) this information pertains to the feed itself (unless otherwise specified) c) this information pertains to each entry and to the feed itself (unless otherwise specified) d) completely unknown unless specified in the extension definition --Paul Hoffman, Director --Internet Mail Consortium
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
Paul Hoffman wrote: At 7:24 PM +0100 8/21/05, Peter Robinson wrote: I do something similar, intending it to mean the location of the items described by this feed (when there is a single location). Ah, I had missed that. This leads to a question for the mailing list. Does an informative extension that appears at the feed level (as compared to in entries) indicate: a) this information pertains to each entry b) this information pertains to the feed itself c) this information pertains to each entry and to the feed itself d) completely unknown unless specified in the extension definition --Paul Hoffman, Director --Internet Mail Consortium IMHO, it depends entirely on how the extension is defined. The various extensions I have put together (e.g. comments, expires, etc), the metadata can be placed on the feed/source level but is only relevant on the entry level (same model as author /). One could easily imagine, however, that other extensions would apply only on the feed level. It's entirely up to the extension and implementors should make no assumptions. - James
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
At 3:35 PM -0700 8/21/05, James M Snell wrote: IMHO, it depends entirely on how the extension is defined. The various extensions I have put together (e.g. comments, expires, etc), the metadata can be placed on the feed/source level but is only relevant on the entry level (same model as author /). One could easily imagine, however, that other extensions would apply only on the feed level. It's entirely up to the extension and implementors should make no assumptions. The crux of the question is: what happens when an extension that does not specify the scope appears at the feed level? --Paul Hoffman, Director --Internet Mail Consortium
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
On 8/21/05, Paul Hoffman [EMAIL PROTECTED] wrote: At 3:35 PM -0700 8/21/05, James M Snell wrote: IMHO, it depends entirely on how the extension is defined. The various extensions I have put together (e.g. comments, expires, etc), the metadata can be placed on the feed/source level but is only relevant on the entry level (same model as author /). 4.1.1 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. 4.2.1 The 'atom:author' element is a Person construct that indicates the author of the entry or feed. One could easily imagine, however, that other extensions would apply only on the feed level. It's entirely up to the extension and implementors should make no assumptions. The crux of the question is: what happens when an extension that does not specify the scope appears at the feed level? I'm not sure why this question is interesting. What sort of application would need to know? Robert Sayre
RE: Extensions at the feed level (Was: Re: geolocation in atom:author?)
Paul Hoffman wrote: The crux of the question is: what happens when an extension that does not specify the scope appears at the feed level? Robert Sayre asked: I'm not sure why this question is interesting. What sort of application would need to know? I ask: What should an aggregate feed generator like PubSub do when it finds an entry in a feed that contains unscoped extensions as children of the feed? * Would you expect us to include these extension elements in an atom:source element if we use the entry in one of our feeds? * Should we include in the source elements we generate even things that we don't understand? * What should we do if the entry already has a source element but that source element doesn't include the extension elements? Should we publish the source element as we find it? Or, should we modify the source element to include the extensions? (assuming there are no signatures...) bob wyman
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
* Paul Hoffman [EMAIL PROTECTED] [2005-08-22 01:00]: The crux of the question is: what happens when an extension that does not specify the scope appears at the feed level? Let me step back to look at the larger issue for a moment. That issue is inheritance. atom:author is the only precedent for it in Atom. It works because each entry ALWAYS has at least one author; the override mechanism is simple. Additionally, all Atom processors are aware of it by definition. But atom:author is not a model to emulate. It works only because it falls within a narrowly defined set of circumstances. The WG wisely avoided attempting to specify inheritance for atom:contributor. An entry MAY have no contributors at all, and this would require complications to express if feed-level atom:contributor elements inherited to entries. My point of view is that the default interpretation should avoid forcing extensions to specify complicated mechanisms that the WG avoided introducing when specifying atom:contributor, when an extension element’s semantics are the same as those of atom:contributor. And with that, getting back to your question, the answer seems pretty clear: it depends on whether the extension element is more like atom:contributor, ie defines a property which an entry may or may not have, or more like atom:author, ie defines a property that every entry inevitably has. But because that is a matter of interpretation, I would strongly prefer to say that if the extension does not specify a meaning for an element at the feed level, then the meaning is undefined. On the other, related point, the same principle of avoiding the necessity of complicated override mechanisms is why I say that aggregators should assume that unknown extension elements (which therefore have *unknown* as opposed to *undefined* semantics) pertain only to the feed, not to its entries. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
RE: Extensions at the feed level (Was: Re: geolocation in atom:author?)
Aristotle Pagaltzis wrote: That issue is inheritance. Let me give an example of problematic inheritance... Some have suggested that there be a License that you can associate with Atom feeds and entries. However, scoping becomes very important in this case because of some peculiarities of the legal system. One can copyright an individual thing and one can copyright a collection of things. A claim of copyright in a collection is not, however, necessarily a claim of copyright over the elements of the collection. Similarly, a claim of copyright over an element of the collection doesn't reduce any claim of copyright in the collection itself. If we assume inheritance from feed elements, then without further specification, it isn't possible to claim copyright in the collection that is the feed without claiming copyright in its individual parts. What you'd have to do is create two distinct types of claim (one for collection and one for item. That's messy.) I'm sure that copyright and licenses aren't the only problematic contexts here. bob wyman
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
A. Pagaltzis wrote: And with that, getting back to your question, the answer seems pretty clear: it depends on whether the extension element is more like atom:contributor, ie defines a property which an entry may or may not have, or more like atom:author, ie defines a property that every entry inevitably has. But because that is a matter of interpretation, I would strongly prefer to say that if the extension does not specify a meaning for an element at the feed level, then the meaning is undefined. On the other, related point, the same principle of avoiding the necessity of complicated override mechanisms is why I say that aggregators should assume that unknown extension elements (which therefore have *unknown* as opposed to *undefined* semantics) pertain only to the feed, not to its entries. Ok, I retract my earlier comment about apps not making any assumptions about unknown extensions. This is better. Regarding Bob Wyman's separate note about what aggregators like pubsub should do, If the aggregator is generating the source element, the aggregator should include everything it finds in the feed.. even if it does not understand it. If the entry already contains a source element, leave it as is. - James
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
* Robin Cover [EMAIL PROTECTED] [2005-08-22 05:05]: On Mon, 22 Aug 2005, A. Pagaltzis wrote: That issue is inheritance. atom:author is the only precedent for it in Atom. If it in only precedent for it refers to inhertance, can you explain the sense in which atom:author is the only precedent ? xml:lang, Sure, then you can also cite xml:base and possibly more. But these are irrelevant – they they work on a different layer and have no concept of “feed-level” or “entry-level.” They’re possibly better described as annotations at the XML level, as opposed to metadata at the Atom model level. And with both of them being attributes, the cardinality is trivial and known in advance: zero or one. Thus the override mechanism is universally obvious in advance. They have nothing in common with extension elements as per the semantics defined in the Atom Format specification. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
Bob Wyman wrote: Aristotle Pagaltzis wrote: That issue is inheritance. Let me give an example of problematic inheritance... Some have suggested that there be a License that you can associate with Atom feeds and entries. However, scoping becomes very important in this case because of some peculiarities of the legal system. One can copyright an individual thing and one can copyright a collection of things. A claim of copyright in a collection is not, however, necessarily a claim of copyright over the elements of the collection. Similarly, a claim of copyright over an element of the collection doesn't reduce any claim of copyright in the collection itself. If we assume inheritance from feed elements, then without further specification, it isn't possible to claim copyright in the collection that is the feed without claiming copyright in its individual parts. What you'd have to do is create two distinct types of claim (one for collection and one for item. That's messy.) I'm sure that copyright and licenses aren't the only problematic contexts here. bob wyman From the format text: 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. This really does not describe an inheritance model*. This describes a scoping model. If an entry does not contain an author, the author on the feed is said to apply. If the entry does happen to have an author, it doesn't matter if the feed also has an author, it is the author element on the entry that applies to the entry. Same thing with the license extension (for example). If both the feed and entry contain license links, it is the license link on the entry that is relevant to the entry. If the entry does not contain a license, it looks to the feed level. Placing a license on the feed level does not change the license of the entry if the entry already has a license. There is another example of this kind of scoping that we're all intimately familiar with: x:a xmlns:x=urn:namespace-1 xmlns=urn:namespace-2 x:b xmlns:x=urn:namespace-3 c / /x:b /x:a From Section 5.1 of Namespaces in XML: The namespace declaration is considered to apply to the element where it is specified and to all elements within the content of that element, unless overridden by another namespace declaration (http://www.w3.org/TR/REC-xml-names/#scoping) To directly address Bob's point that it isn't possible to claim copyright in the collection that is the feed without claiming copyright in its individual parts -- it IS possible if we are looking at this in terms of relevant scope as opposed to inherited properties. Note to self: I need to fix the license spec to address this. Currently the spec limits the license relevance to entries without providing a mechanism for attaching a license to the feed itself. Second note to self: After thinking about this a bit more, I would also need a way of specifying a null license (e.g. the lack of a license). For instance, what if an entry that does not contain a license is aggregated into a feed that has a license. The original lack-of-license still applies to that entry regardless of what is specified on the feed level. Golly Bob, you're right, this is rather messy ain't it. Hmm... - James * I've called this inheritance in the past but now I do believe that I was mistaken.
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
A. Pagaltzis wrote: * Robin Cover [EMAIL PROTECTED] [2005-08-22 05:05]: On Mon, 22 Aug 2005, A. Pagaltzis wrote: That issue is inheritance. atom:author is the only precedent for it in Atom. If it in only precedent for it refers to inhertance, can you explain the sense in which atom:author is the only precedent ? xml:lang, Sure, then you can also cite xml:base and possibly more. But these are irrelevant – they they work on a different layer and have no concept of “feed-level” or “entry-level.” They’re possibly better described as annotations at the XML level, as opposed to metadata at the Atom model level. And yet in the spec we constrain the relevance of xml:lang and xml:base to specific elements. Sure, they operate on the XML level, but they do have relevance on the feed/entry level. Not that this changes your argument, it's just an observation that xml:lang and xml:base are not entirely dissimilar to atom:author. - James
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
* James M Snell [EMAIL PROTECTED] [2005-08-22 05:30]: Second note to self: After thinking about this a bit more, I would also need a way of specifying a null license (e.g. the lack of a license). For instance, what if an entry that does not contain a license is aggregated into a feed that has a license. The original lack-of-license still applies to that entry regardless of what is specified on the feed level. Golly Bob, you're right, this is rather messy ain't it. Hmm... This is exactly the point I was making about atom:contributor. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
