* 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

Reply via email to