* 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