Re: A different question about atom:author and inheritance
Sunday, May 22, 2005, 9:53:23 PM, Robert Sayre wrote: The draft hasn't changed for more than a month, while Tim and Paul have been last-calling this thing for months now, and very little of substance has transpired since then. The document has been quite stable since March 12th, when format-06 was produced. No, the draft hasn't changed in the last month, but it will do when draft-09 is released. I was talking about the batch of proposals, including PaceAllowDuplicateIDs (a fundamental change), that were accepted 4 days ago. http://www.imc.org/atom-syntax/mail-archive/msg15289.html -- Dave
A different question about atom:author and inheritance
I am concerned that the requirement: atom:feed elements MUST contain exactly one atom:author element, UNLESS all of the atom:feed element's child atom:entry elements contain an atom:author element. ...suggests that some sort of inheritance goes on, but such a mechanism isn't obvious and isn't described anywhere. Draft -06 had a comment from Robert in there saying that inheritance needed explaining, but I can't see where this issue was resolved. Are these interpretations correct? They are personal opinions. Does the spec back them up? a) feed authornameA/name/author entry /entry /feed The author of the feed is A. (perhaps in some editorial capacity) The author of the entry is A. b) feed entry authornameA/name/author /entry /feed The author of the feed is undefined. The author of the entry is A. c) feed entry source authornameB/name/author /source /entry /feed The author of the feed is undefined. The author of the entry is B. The author of the source feed is B. -- Dave
Re: A different question about atom:author and inheritance
On 5/22/05, David Powell [EMAIL PROTECTED] wrote: I am concerned that the requirement: atom:feed elements MUST contain exactly one atom:author element, UNLESS all of the atom:feed element's child atom:entry elements contain an atom:author element. ...suggests that some sort of inheritance goes on, but such a mechanism isn't obvious and isn't described anywhere. Draft -06 had a comment from Robert in there saying that inheritance needed explaining, but I can't see where this issue was resolved. The WG decided it wasn't worth specifying any more tightly. The sentence you quoted states a cardinality requirement. Inheritance was floated around, but the WG ultimately went with the language that's in the draft. It forces you to have an author element in there somewhere, but doesn't make logical assertions in the style of an RDF vocabulary. Robert Sayre
Re: A different question about atom:author and inheritance
On 5/22/05, David Powell [EMAIL PROTECTED] wrote: comment from Robert in there saying that inheritance needed explaining, but I can't see where this issue was resolved. Oops. Here's the discussion: http://www.imc.org/atom-syntax/mail-archive/msg13793.html Here's what the chairs said: http://www.imc.org/atom-syntax/mail-archive/msg13784.html I suppose we could drop some more of that proposed stuff in, but I think the first bullet points of 4.1.1 and 4.1.2 cover it adequately. Besides, no one indicated they were unhappy with that text in WG last call or IETF last call. Robert Sayre
Re: A different question about atom:author and inheritance
Sunday, May 22, 2005, 7:04:41 PM, Robert Sayre wrote: On 5/22/05, David Powell [EMAIL PROTECTED] wrote: comment from Robert in there saying that inheritance needed explaining, but I can't see where this issue was resolved. Oops. Here's the discussion: http://www.imc.org/atom-syntax/mail-archive/msg13793.html Here's what the chairs said: http://www.imc.org/atom-syntax/mail-archive/msg13784.html I suppose we could drop some more of that proposed stuff in, but I think the first bullet points of 4.1.1 and 4.1.2 cover it adequately. Ok - it looks like my interpretations were wrong. The spec doesn't condone any kind of inheritance of atom:author from feeds to entries. The requirement that either the feed or all entries contain atom:author misled me. So would these interpretations be correct: a) feed authornameA/name/author entry /entry /feed The author of the feed is A. The author of the entry is undefined. b) feed entry authornameA/name/author /entry /feed The author of the feed is undefined. The author of the entry is A. c) feed entry source authornameB/name/author /source /entry /feed The author of the feed is undefined. The author of the entry is undefined. The author of the source feed is B. I think that the current text is very misleading. The fact that at one point inheritance has been condoned or suggested by previous drafts (including the widely implemented pre-IETF public draft), but now we have removed the suggestion, but kept the syntactic requirement certainly got me. The fact that the draft conflates the author (editor?) of the feed with the author of the entries increases the confusion. We should add language that specifically states that the value of atom:feed/atom:author is not a shortcut for specifying atom:entry/atom:author - if that is what we mean. (Hopefully, the WG agree that this is the intended meaning of the author element? It would be a hugely embarrassing to define a simple element in a completely ambiguous way, when RSS2.0 is crystal clear on the matter.) -- Dave
Re: A different question about atom:author and inheritance
Sunday, May 22, 2005, 7:04:41 PM, Robert Sayre wrote: Besides, no one indicated they were unhappy with that text in WG last call or IETF last call. Sorry, I was too busy reviewing the 23 additional Paces that were proposed during IETF Last-Call to have time to sufficiently review the specification itself. We may of thought that we were finished, but it is clear that we were not ready for Last-Call: neither the Working Group, nor the IETF had sufficient time to review the specification because it has been in flux with proposals. Major changes such as PaceDuplicateIDs have been added and nobody has seen the draft yet, let alone reviewed it. The fact that both myself and the editor were confused about whether a contentious paragraph had been accepted by the chairs, demonstrates this problem. http://www.imc.org/atom-syntax/mail-archive/msg15476.html -- Dave
Re: A different question about atom:author and inheritance
On 5/22/05, David Powell [EMAIL PROTECTED] wrote: We may of thought that we were finished, but it is clear that we were not ready for Last-Call: neither the Working Group, nor the IETF had sufficient time to review the specification because it has been in flux with proposals. You know, thinking more about this one, it makes me more irritated than I already am. If it's less flux you desire, there's a very easy way to make that happen. The chairs could simply declare paces which revisit issues the group has already decided to be out of order. The fact that they've tolerated yet more discussion on things like atom:modified and archiving, which brought exactly zero bits of new information to the discussion, speaks volumes about their patience. I take a less diplomatic view of the past few days... Robert Sayre
Re: A different question about atom:author and inheritance
On 5/22/05, David Powell [EMAIL PROTECTED] wrote: I think that the current text is very misleading. The fact that at one point inheritance has been condoned or suggested by previous drafts (including the widely implemented pre-IETF public draft), but now we have removed the suggestion, but kept the syntactic requirement certainly got me. So, are you saying that we're required to explicitly reverse any requirement present in previous drafts? The fact that the draft conflates the author (editor?) of the feed with the author of the entries increases the confusion. Where does the draft conflate the two? Robert Sayre
Re: A different question about atom:author and inheritance
Sunday, May 22, 2005, 10:25:29 PM, Robert Sayre wrote: On 5/22/05, David Powell [EMAIL PROTECTED] wrote: I think that the current text is very misleading. The fact that at one point inheritance has been condoned or suggested by previous drafts (including the widely implemented pre-IETF public draft), but now we have removed the suggestion, but kept the syntactic requirement certainly got me. So, are you saying that we're required to explicitly reverse any requirement present in previous drafts? No, we're required to state the situation one way or the other. The current draft doesn't say that author is inherited, so I assumed that my original interpretation was incorrect. If it is intended to be inherited, can we still add text saying that it is inherited as an editorial change? The fact that the draft conflates the author (editor?) of the feed with the author of the entries increases the confusion. Where does the draft conflate the two? Given this feed, how should it be displayed by an implementation? feed xmlns=http://purl.org/atom/ns#draft-ietf-atompub-format-08; author nameDavid Powell/name /author titleAn example feed/title updated2005-05-22T21:35:00Z/updated link rel=alternate href=http://example.com/feeduri; / entry idhttp://example.com/entries/1/id titleWho wrote this?/title content type=textThe content should go here.../content updated2005-05-22T21:35:00Z/updated /entry /feed Is this correct: Who wrote this? === The content should go here... Last updated: 22nd May 2005 by David Powell Or was David Powell only intended to be the author (editor?) of the feed, and has the entry therefore been mis-attributed? -- Dave
Re: A different question about atom:author and inheritance
On 5/22/05, David Powell [EMAIL PROTECTED] wrote: So, are you saying that we're required to explicitly reverse any requirement present in previous drafts? No, we're required to state the situation one way or the other. The current draft doesn't say that author is inherited, so I assumed that my original interpretation was incorrect. If it is intended to be inherited, can we still add text saying that it is inherited as an editorial change? We can clarify and improve the draft to your heart's delight. It's unproductively revisiting old arguments that bothers me. :) Given this feed, how should it be displayed by an implementation? My problem is that the draft (wisely) doesn't make requirements about what implementations should 'display'. Shrook and PubSub.com are both 'implementations' and both may or may not 'display' authors, either of a feed or an entry. Here is the code that determines what to put in the From field when Thunderbird parses an RSS2 feed: item.author = getNodeValue(itemNode.getElementsByTagName(author)[0] || itemNode.getElementsByTagName(creator)[0]) || aFeed.title || item.author; That's not particularly sophisticated. I think the author of that code assumed finding the author would be Really Simple. Are you suggesting we can specify what that code should do, briefly, usefully, and clearly? If so, let's hear it. My personal opinion is that the best way for publishers to ensure their preferred text is displayed is to put an author element in the atom:entry. Of course, code like the stuff above wouldn't pick up multiple atom:author elements (just thought I'd mix it up :) Robert Sayre
Re: A different question about atom:author and inheritance
On May 22, 2005, at 3:10 PM, Robert Sayre wrote: If it is intended to be inherited, can we still add text saying that it is inherited as an editorial change? We can clarify and improve the draft to your heart's delight. It's unproductively revisiting old arguments that bothers me. :) Yeah, I was startled just now to realize that there's nothing there to say that the feed-level author applies to entry-level when it's not specified at the entry level. The intent seems pretty clear; entry-level overrides source-level overrides feed-level, but it seems like we should say that. Anybody think this is anything more than an editorial change? -Tim
Re: A different question about atom:author and inheritance
Tim Bray wrote: Anybody think this is anything more than an editorial change? -Tim Not me (you'd have to tell me that inheritance applies at all, not the other way around). But the rules must be consistent for the elements that appear at both levels. cheers Bill
RE: A different question about atom:author and inheritance
Tim Bray wrote: The intent seems pretty clear; entry-level overrides source-level overrides feed-level, but it seems like we should say that. Anybody think this is anything more than an editorial change? -Tim I believe that this three-level chain of inheritance has always been what we've intended. There was, however, a great deal of discussion at one point about how to actually write the words. Thus, I agree that it is largely an editorial change; however, you might expect some controversy over particular word choices. Give it a shot and let's see how folk respond. Note: There is more to authorship than just the inheritance issue. I think it also makes sense that a feed-level author should be considered to be the author of the collection of items which is the feed. This authorship is independent of authorship over any particular entry within the feed. Even if the feed contains no items authored by the feed-level author, the feed-level author is still author of the collection. This distinction would be useful in describing linkblogs, and a variety of other feeds types that are composed of entries collected from other feeds or multiple authors. bob wyman
Re: A different question about atom:author and inheritance
Bill de hÓra wrote: Tim Bray wrote: Anybody think this is anything more than an editorial change? -Tim Not me (you'd have to tell me that inheritance applies at all, not the other way around). But the rules must be consistent for the elements that appear at both levels. Quick followup: I'll take an action to review the upcoming format draft to see if we need to apply any such wording to feed level extensions. cheers Bill
Re: A different question about atom:author and inheritance
On 5/22/05, Bob Wyman [EMAIL PROTECTED] wrote: Tim Bray wrote: The intent seems pretty clear; entry-level overrides source-level overrides feed-level, but it seems like we should say that. Anybody think this is anything more than an editorial change? -Tim I believe that this three-level chain of inheritance has always been what we've intended. There was, however, a great deal of discussion at one point about how to actually write the words. Thus, I agree that it is largely an editorial change; Fully agree. Robert Sayre
Re: A different question about atom:author and inheritance
Monday, May 23, 2005, 12:20:21 AM, Bob Wyman wrote: Tim Bray wrote: The intent seems pretty clear; entry-level overrides source-level overrides feed-level, but it seems like we should say that. Anybody think this is anything more than an editorial change? -Tim I believe that this three-level chain of inheritance has always been what we've intended. There was, however, a great deal of discussion at one point about how to actually write the words. Thus, I agree that it is largely an editorial change; however, you might expect some controversy over particular word choices. Give it a shot and let's see how folk respond. +1 Note: There is more to authorship than just the inheritance issue. I think it also makes sense that a feed-level author should be considered to be the author of the collection of items which is the feed. This authorship is independent of authorship over any particular entry within the feed. Even if the feed contains no items authored by the feed-level author, the feed-level author is still author of the collection. This distinction would be useful in describing linkblogs, and a variety of other feeds types that are composed of entries collected from other feeds or multiple authors. +1 I think it would be best if we stated both of these effects close together in the specification so that it is obvious what the effect of providing atom:feed/atom:author is. We should also do a check on: atom:feed/atom:category atom:feed/atom:contributor atom:feed/atom:copyright to make sure that we are as clear as possible about whether or not they are inherited by entries, and whether or not they apply to the feed as a itself. -- Dave
Re: A different question about atom:author and inheritance
On 23/5/05 6:01 AM, David Powell [EMAIL PROTECTED] wrote: We should add language that specifically states that the value of atom:feed/atom:author is not a shortcut for specifying atom:entry/atom:author - if that is what we mean. +1 for disambiguating either way. e.
Re: A different question about atom:author and inheritance
On 5/22/05, David Powell [EMAIL PROTECTED] wrote: We may of thought that we were finished, but it is clear that we were not ready for Last-Call: neither the Working Group, nor the IETF had sufficient time to review the specification because it has been in flux with proposals. I can't agree with that statement. The draft hasn't changed for more than a month, while Tim and Paul have been last-calling this thing for months now, and very little of substance has transpired since then. The document has been quite stable since March 12th, when format-06 was produced. Robert Sayre
Re: A different question about atom:author and inheritance
On 23/5/05 8:53 AM, Tim Bray [EMAIL PROTECTED] wrote: Yeah, I was startled just now to realize that there's nothing there to say that the feed-level author applies to entry-level when it's not specified at the entry level. The intent seems pretty clear; entry-level overrides source-level overrides feed-level, but it seems like we should say that. Anybody think this is anything more than an editorial change? -Tim I don't think we ever decided AGAINST inheritance, we only punted on explaining it. Thus, I've assumed that inheritance was implied. That reading the spec in isolation is ambiguous makes it a bad spec. We don't need a Pace, this is an editorial change. The editor might insist on camera ready copy though -- I hear he's a bit curmudgeonly lately. e.
