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
