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: ... ... ... -- 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 it’s 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 that’s not going to change… I’m not opting for the best possible solution; I’m 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 don’t 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)
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 (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: > > * 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 (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
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)
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)
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 9:56 AM, "Graham" <[EMAIL PROTECTED]> wrote: > I'd say it draws from atom:source OR atom:feed. > You meant atom:source XOR atom:feed? > atom:feed should not be used if atom:source exists, even if it doesn't > contain an atom:author, which it SHOULD. > (well, it SHOULD, unless atom:entry already contains atom:author, right?) > (unrelated question: what's with this plus sign " & atomLink+" in the > atom:source production?) > well spotted. 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 (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.