Re: inheritance issues (was: Author and contributor)
A. Pagaltzis wrote: * Thomas Broyer [2005-05-24 15:15]: A. Pagaltzis wrote: * Thomas Broyer [2005-05-24 09:05]: c) feed: author: A contributor: B entry: contributor: C [...] c) The entry inherits the author but overrides the contributor. I'm also open to considering it invalid. [...] If you just consider c) to be invalid, you can go with: A non-empty set of both atom:entry/atom:author and atom:entry/atom:contributor overrides any set of both atom:feed/atom:author and atom:feed/atom:contributor. That seems to allow entries with contributors, but no author. You need to be more precise. It doesn't: I didn't say I'd remove the following bullets ;o) in 4.1.1: o 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. and 4.1.2: o atom:entry elements MUST contain exactly one atom:author element, unless the atom:entry contains an atom:source element which contains an atom:author element, or, in an Atom Feed Document, the atom:feed element contains an atom:author element itself. or If an atom:entry has neither an atom:author nor an atom:contributor child element, the author(s) of and contributor(s) to the entry are those specified at the feed level, that is, those appearing as children of an atom:source or, if the atom:entry contains no atom:source child element, those appearing as children of the atom:feed element. Note that if an entry has no atom:author or atom:contributor child but contains an atom:source child. If the atom:source element contains no atom:author or atom:contributor child, the entry has no author or contributor. In such a case, the atom:author and atom:contributor children of the atom:feed element don't cascade into the atom:entry. (and again, excuse me for my English, it's not my mother tong) I think this clearly demonstrates why I opted for disallowing atom:contributor in absence of ../atom:author: it is difficult to explain. You need a lot of prose to express it. You also need more code and more grammar rules. To me, that raises flags that it’s too complex. Actually, only the first paragraph addresses the author/contributor grouping. The second one might still be necessary to disambiguate the entry - (source XOR feed) inheritance mechanism. Btw, had you seen the above bullet in 4.1.1 doesn't allow for a feed with only imported entries (with atom:source) to be author-less? The following feed is invalid per the current draft: atom:feed xmlns:atom=...Atom NS... atom:entry atom:source atom:authoratom:name.../atom:name/atom:author ... /atom:source ... /atom:entry /atom:feed -- Thomas Broyer
Re: inheritance issues (was: Author and contributor)
A. Pagaltzis wrote: * Eric Scheid [EMAIL PROTECTED] [2005-05-24 01:40]: Consider too a feed which has both authors and contributors at the feed level, an entry with neither authors or contributors (simple case of inheritance), and another entry with a single author and no contributors (does the entry inherit the feed contributors?), and a third entry with no specified author (inherits, right?), but with contributors (no inheritance, right?). The first case is easy to guess the intention. The third case is easy to guess the intention. It's the second case which is the beotch. I think of these things in terms of what is possible to express. a) Any entry always has an author. Right, I forgot that. Actually, I was reading the format-08 inlined RNC, which doesn't include the schematron rules. Could there be some improvement to the spec? b) A feed may or may not have an author. c) An entry may or may not have contributors. d) A feed may or may not have contributors. Any solution must not prevent any of these from being expressible. I already discussed why replacement is preferrable to merging when any of these are given at both the feed and entry level. Now with that in mind, c) and d) suggest to me that atom:feed/atom:contributor never inherits to entries. If entries were to inherit from the feed, then in a feed with contributors it is not possible to express that an entry had no contributors. Not if you consider the group formed by the authors and contributors. Hmm, what about that: feed level contributors cascade to the entry level only when there is an atom:author element at the feed level which also cascades. Er, I might be not quite clear, so let's see examples: how would you interpret the following? a) feed: author: A contributor: B entry: no author not contributor b) feed: author: A contributor: B entry: author: C c) feed: author: A contributor: B entry: contributor: C d) feed: contributor: A entry: author: B contributor: C e) feed: contributor: A entry: author: B Other cases don't have any problem (or I missed it) or are invalid (e.g. no author at all) a) The entry inherits both the author and contributor from the feed. b) The entry inherits nothing from the feed. c) The entry inherits the author but overrides the contributor. I'm also open to considering it invalid. d) The entry inherits nothing from the feed. e) The entry inherits nothing from the feed. Let's see what others have to say about this and then find the appropriate wording. So in summary: The set of atom:entry/atom:author overrides the set of atom:feed/atom:author for a particular entry, should the set be non-empty. [Inheritance with replacement semantics.] The set of atom:feed/atom:contributor applies only to the feed and not to any of its entries. [No inheritance.] I'm not opposed to that but it might not be obvious in the a) example above. -- Thomas Broyer
Re: inheritance issues
Simplify, simplify. I am for removing all inheritance mechanisms... Henry On 24 May 2005, at 02:02, Bill de hÓra wrote: Eric Scheid wrote: oh darn. This damn inheritance stuff is nasty. Inheritance suggests a programming model to allow the evaluator to be coded for it. It's rarely as simple as it looks to define a decent model that does what people think it does at first glance. As things stand, it will be an immense coincidence if we do not end up dishing out nasty surprises for users. Atom's just not a very good programming language ;) cheers Bill
Re: inheritance issues (was: Author and contributor)
* Thomas Broyer [EMAIL PROTECTED] [2005-05-24 09:05]: a) feed: author: A contributor: B entry: no author not contributor b) feed: author: A contributor: B entry: author: C c) feed: author: A contributor: B entry: contributor: C d) feed: contributor: A entry: author: B contributor: C e) feed: contributor: A entry: author: B a) The entry inherits both the author and contributor from the feed. b) The entry inherits nothing from the feed. c) The entry inherits the author but overrides the contributor. I'm also open to considering it invalid. d) The entry inherits nothing from the feed. e) The entry inherits nothing from the feed. Let's see what others have to say about this and then find the appropriate wording. Thanks for taking the time to spell out combinations; good food for thought. You are right that the entry in a) not inheriting contributors, as per my proposed rules, would be counterintuitive. The rule you propose for contributor semi-inheritance is hard to explain clearly in prose and somewhat convoluted to implement in code though. And while I have not gotten around to learning RELAX NG, it also seems that it would be non-trivial to express as any form of grammar. After looking at all these cases, I would instead suggest that we prohibit atom:contributor in absence of an atom:author at the same level. That would make all of c), d) and e) invalid. Note that the semantics you propose for c), d) and e) are still expressible, they just require more repetition. Effectively, I am proposing: A non-empty set of atom:entry/atom:author overrides any set of atom:feed/atom:author and atom:feed/atom:contributor. atom:contributor may only appear if ../atom:author is also given. That seems like it would isolate the specification of atom:contributor from any inheritance issues, whose discussion could be confined to the specification of atom:author. The only constellation that would have been possible with your proposed set of restrictions, which my set of restrictions no longer allow, is expressing that feed has only contributors, but no authors. If anyone feels that such feeds must be expressible, then the restrictions could be loosened so that only atom:entry/atom:contributor requires an ../atom:author; however, as long as noone feels that way, I suggest that the restriction be symmetric to simplify specification and implementation. Regards, -- Aristotle
Re: inheritance issues (was: Author and contributor)
A. Pagaltzis wrote: * Thomas Broyer [2005-05-24 09:05]: c) feed: author: A contributor: B entry: contributor: C [...] c) The entry inherits the author but overrides the contributor. I'm also open to considering it invalid. [...] The rule you propose for contributor semi-inheritance is hard to explain clearly in prose and somewhat convoluted to implement in code though. And while I have not gotten around to learning RELAX NG, it also seems that it would be non-trivial to express as any form of grammar. After looking at all these cases, I would instead suggest that we prohibit atom:contributor in absence of an atom:author at the same level. That would make all of c), d) and e) invalid. Note that the semantics you propose for c), d) and e) are still expressible, they just require more repetition. Effectively, I am proposing: A non-empty set of atom:entry/atom:author overrides any set of atom:feed/atom:author and atom:feed/atom:contributor. atom:contributor may only appear if ../atom:author is also given. If you just consider c) to be invalid, you can go with: A non-empty set of both atom:entry/atom:author and atom:entry/atom:contributor overrides any set of both atom:feed/atom:author and atom:feed/atom:contributor. or If an atom:entry has neither an atom:author nor an atom:contributor child element, the author(s) of and contributor(s) to the entry are those specified at the feed level, that is, those appearing as children of an atom:source or, if the atom:entry contains no atom:source child element, those appearing as children of the atom:feed element. Note that if an entry has no atom:author or atom:contributor child but contains an atom:source child. If the atom:source element contains no atom:author or atom:contributor child, the entry has no author or contributor. In such a case, the atom:author and atom:contributor children of the atom:feed element don't cascade into the atom:entry. (and again, excuse me for my English, it's not my mother tong) Actually, the proposed rule is the same as having an atom:person element with a role property (attribute or child element) and a rule which says: A non-empty set of atom:entry/atom:person overrides any set of atom:feed/atom:person. And you replace everywhere in spec atom:author with atom:person with a role equal to 'author' and atom:contributor with atom:person with a role equal to 'contributor'. Please note that I am not proposing changing atom:author and atom:contributor to atom:person with a role property. This is just to make clearer my proposal of considering atom:author's and atom:contributor's as a whole, not atom:author's in one hand and atom:contributor's in the other hand. That seems like it would isolate the specification of atom:contributor from any inheritance issues, whose discussion could be confined to the specification of atom:author. We're talking about authors and contributors but inheritance is to be explicitly defined for (copy)rights, categories, etC. as well. The only constellation that would have been possible with your proposed set of restrictions, which my set of restrictions no longer allow, is expressing that feed has only contributors, but no authors. If anyone feels that such feeds must be expressible, then the restrictions could be loosened so that only atom:entry/atom:contributor requires an ../atom:author; however, as long as noone feels that way, I suggest that the restriction be symmetric to simplify specification and implementation. -0 to forbidding contributors without author at the feed level. -- Thomas Broyer
Re: inheritance issues
On Tuesday, May 24, 2005, at 01:52 AM, Henry Story wrote: Simplify, simplify. I am for removing all inheritance mechanisms... I would agree if we had a better way to avoid all the repetition that would lead to. However, the only proposal[0] I can remember that would have done so has been rejected by the WG. I'm torn on whether to bring this up (I'd like to see it done, but it's getting late), but looking at the reasons given for rejecting PacePersonRef [1][2][3], recent discussion of author, contributor and inheritance suggests that the opposition may have been mistaken. See also [4]. Eric Scheid wrote: oh darn. This damn inheritance stuff is nasty. [0] http://www.intertwingly.net/wiki/pie/PacePersonRef [1] http://www.imc.org/atom-syntax/mail-archive/msg09290.html [2] http://www.imc.org/atom-syntax/mail-archive/msg09490.html [3] http://www.imc.org/atom-syntax/mail-archive/msg11531.html [4] http://www.imc.org/atom-syntax/mail-archive/msg11530.html
Re: inheritance issues
Antone Roundy wrote: On Tuesday, May 24, 2005, at 01:52 AM, Henry Story wrote: Simplify, simplify. I am for removing all inheritance mechanisms... I would agree if we had a better way to avoid all the repetition that would lead to. However, the only proposal[0] I can remember that would have done so has been rejected by the WG. I'm torn on whether to bring this up (I'd like to see it done, but it's getting late), but looking at the reasons given for rejecting PacePersonRef [1][2][3], recent discussion of author, contributor and inheritance suggests that the opposition may have been mistaken. See also [4]. I wasn't there at the time PacePersonRef was proposed. Here's what I'd have said if I were: -1 to dropping inheritance mechanism, this leads to repetitions of atom:author and atom:contributor in each entry +1 to id references as a way to allow factorization of people on one place and thus saves some bytes by preventing the repetition of the Person metadata (it might reveal even much better later when there will be extensions to the Person constructs, e.g. FOAF, which might be quite verbose). +0 on whether to use an atom:people container. I'd way prefer clear and clean inheritance definition to repeating metadata all the way down, even if the metadata uses references to metadata elements defined elsewhere. -- Thomas Broyer
Re: inheritance issues (was: Author and contributor)
* Thomas Broyer [EMAIL PROTECTED] [2005-05-24 15:15]: A. Pagaltzis wrote: * Thomas Broyer [2005-05-24 09:05]: c) feed: author: A contributor: B entry: contributor: C [...] c) The entry inherits the author but overrides the contributor. I'm also open to considering it invalid. [...] Effectively, I am proposing: A non-empty set of atom:entry/atom:author overrides any set of atom:feed/atom:author and atom:feed/atom:contributor. atom:contributor may only appear if ../atom:author is also given. If you just consider c) to be invalid, you can go with: A non-empty set of both atom:entry/atom:author and atom:entry/atom:contributor overrides any set of both atom:feed/atom:author and atom:feed/atom:contributor. That seems to allow entries with contributors, but no author. You need to be more precise. or If an atom:entry has neither an atom:author nor an atom:contributor child element, the author(s) of and contributor(s) to the entry are those specified at the feed level, that is, those appearing as children of an atom:source or, if the atom:entry contains no atom:source child element, those appearing as children of the atom:feed element. Note that if an entry has no atom:author or atom:contributor child but contains an atom:source child. If the atom:source element contains no atom:author or atom:contributor child, the entry has no author or contributor. In such a case, the atom:author and atom:contributor children of the atom:feed element don't cascade into the atom:entry. (and again, excuse me for my English, it's not my mother tong) I think this clearly demonstrates why I opted for disallowing atom:contributor in absence of ../atom:author: it is difficult to explain. You need a lot of prose to express it. You also need more code and more grammar rules. To me, that raises flags that its too complex. Only the atom:content section of the specification contains restrictions on any single aspect which are not expressible in one or two sentences and cannot be understood in near isolation. Please note that I am not proposing changing atom:author and atom:contributor to atom:person with a role property. This is just to make clearer my proposal of considering atom:author's and atom:contributor's as a whole, not atom:author's in one hand and atom:contributor's in the other hand. It would be much easier to explain your proposal if that were the case; and in that case I would be in favour. But we have two separate elements, and thats not going to change Im not opting for the best possible solution; Im trying to suggest something that, given the current state of the specification, will require the least changes for the most effect. -0 to forbidding contributors without author at the feed level. Actually, me too. Banning feeds with only contributors does not make the actual documents any more precise, so conceptually I dont like the restriction. But it makes everything that deals with the documents simpler, so I accept it. Regards, -- Aristotle
Re: inheritance issues (was: Author and contributor)
On 24/5/05 9:02 AM, Thomas Broyer [EMAIL PROTECTED] wrote: The problem is mostly when there are author(s) without contributor in the feed (resp. entry) and contributor(s) without author in the entry (resp. feed). Is the entry author-less (resp. contributor-less) or is it inheriting the feed author(s) (resp. contributor(s))? I suggest considering author(s)+contributor(s) as a whole, that is, the entry would be author-less (resp. contributor-less). This issue would not exist if there couldn't be an atom:contributor without at least an atom:author, though I'm not sure this wouldn't bring some more issues... oh darn. This damn inheritance stuff is nasty. Consider too a feed which has both authors and contributors at the feed level, an entry with neither authors or contributors (simple case of inheritance), and another entry with a single author and no contributors (does the entry inherit the feed contributors?), and a third entry with no specified author (inherits, right?), but with contributors (no inheritance, right?). The first case is easy to guess the intention. The third case is easy to guess the intention. It's the second case which is the beotch. Second area of concern with writing the spec text - the atom:source element needs to be mentioned in the text about inheritance. My understanding is that inheritance draws first from atom:source (if it exists), and then atom:feed. e.
Re: inheritance issues (was: Author and contributor)
On 24 May 2005, at 12:31 am, Eric Scheid wrote: Second area of concern with writing the spec text - the atom:source element needs to be mentioned in the text about inheritance. My understanding is that inheritance draws first from atom:source (if it exists), and then atom:feed. I'd say it draws from atom:source OR atom:feed. atom:feed should not be used if atom:source exists, even if it doesn't contain an atom:author, which it SHOULD. (unrelated question: what's with this plus sign atomLink+ in the atom:source production?) Graham
Re: inheritance issues
Eric Scheid wrote: oh darn. This damn inheritance stuff is nasty. Inheritance suggests a programming model to allow the evaluator to be coded for it. It's rarely as simple as it looks to define a decent model that does what people think it does at first glance. As things stand, it will be an immense coincidence if we do not end up dishing out nasty surprises for users. Atom's just not a very good programming language ;) cheers Bill
Re: inheritance issues (was: Author and contributor)
On 5/23/05, Eric Scheid [EMAIL PROTECTED] wrote: On 24/5/05 9:56 AM, Graham [EMAIL PROTECTED] wrote: (unrelated question: what's with this plus sign atomLink+ in the atom:source production?) well spotted. That means oneOrMore, while * means zeroOrMore. + is accurate for format-08, which requires an alternate link. Robert Sayre
Re: inheritance issues (was: Author and contributor)
On 24/5/05 10:36 AM, Robert Sayre [EMAIL PROTECTED] wrote: On 5/23/05, Eric Scheid [EMAIL PROTECTED] wrote: On 24/5/05 9:56 AM, Graham [EMAIL PROTECTED] wrote: (unrelated question: what's with this plus sign atomLink+ in the atom:source production?) well spotted. That means oneOrMore, while * means zeroOrMore. + is accurate for format-08, which requires an alternate link. and yet atom:source goes at length to say it is optional, and also some or all metadata elements could be copied, and while it encourages the copying of atom:author, atom:contributor, atom:copyright, and atom:category, the spec text provides no guidance or requirement that [EMAIL PROTECTED] MUST be copied. The text is normative, the rnc is not, and on that distinction it would be valid to not copy any links. Alternatively, it would also be entirely valid (given the spec text there), to copy some other link (eg. @rel=self) and not copy the @rel=alternate link at all. Is this what we meant the spec to say? e.
Re: inheritance issues (was: Author and contributor)
If an atom:entry is copied from one feed into another feed, then the source atom:feed's metadata (all child elements of atom:feed other than the atom:entry elements) MAY be preserved within the copied entry by adding an atom:source child element, if it is not already present in the entry, and including some or all of the source feed's metadata elements as the atom:source element's children. Such metadata SHOULD be preserved if the source atom:feed contains any of the child elements atom:author, atom:contributor, atom:copyright, or atom:category and those child elements are not present in the source atom:entry. On 5/23/05, Eric Scheid [EMAIL PROTECTED] wrote: and yet atom:source goes at length to say it is optional, Disagree, the MAY is about putting atom:source in at all (yes, it's possible to copy entries without using atom:source). The text implies that the source must be an atom:feed element, and those have required elements. The RNC also requires atom:title and atom:updated, etc. I guess we could add All required feed metadata elements MUST be present. OK? Robert Sayre
Re: inheritance issues (was: Author and contributor)
* Eric Scheid [EMAIL PROTECTED] [2005-05-24 01:40]: Consider too a feed which has both authors and contributors at the feed level, an entry with neither authors or contributors (simple case of inheritance), and another entry with a single author and no contributors (does the entry inherit the feed contributors?), and a third entry with no specified author (inherits, right?), but with contributors (no inheritance, right?). The first case is easy to guess the intention. The third case is easy to guess the intention. It's the second case which is the beotch. I think of these things in terms of what is possible to express. a) Any entry always has an author. b) A feed may or may not have an author. c) An entry may or may not have contributors. d) A feed may or may not have contributors. Any solution must not prevent any of these from being expressible. I already discussed why replacement is preferrable to merging when any of these are given at both the feed and entry level. Now with that in mind, c) and d) suggest to me that atom:feed/atom:contributor never inherits to entries. If entries were to inherit from the feed, then in a feed with contributors it is not possible to express that an entry had no contributors. With atom:author we can inherit safely, because a) means that there is no case in which an entry can have no author, which means that specifying an inheritable author at the feed level does not pose a problem in expressing any of the possible cases for an entry. So in summary: The set of atom:entry/atom:author overrides the set of atom:feed/atom:author for a particular entry, should the set be non-empty. [Inheritance with replacement semantics.] The set of atom:feed/atom:contributor applies only to the feed and not to any of its entries. [No inheritance.] Any permissible assertion about the feed and one of its entries is thus possible. Regards, -- Aristotle
