Subject: Re: Author and contributor

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 23 May 2005 07:22:49 +0200

* Tim Bray <[email-masked]> [2005-05-23 07:00]:
> Unfortunately, among those who want to change the current
> setup, we do not observe consensus on the subject of what to
> change them to. Near as we can tell, people want to make
> atom:author plural, some want to nuke atom:contributor and
> others don't.

In <[email-masked]>
(<http://www.imc.org/atom-syntax/mail-archive/msg15517.html>),
Antone Roundy suggests:
• make atom:author plural
• keep atom:contributor
• punt bylines to an extension

To me that sounds like the simplest thing that can possibly work,
and looks like it hits the 80/20 mark. It also requires the least
squabbling over its implementation. And Robert has expressed that
he is fine with the proposal in that thread.

I’ve expressed an affinity for the idea of putting atom:category
in atom:contributor, but I see a lot of potential delay in that
and no pressing need for it.

Again, +1 to Antone’s suggestion.

Regards,
-- 
Aristotle

---

From: Eric Scheid <[email-masked]>
Date: Mon, 23 May 2005 15:48:17 +1000

On 23/5/05 3:22 PM, "A. Pagaltzis" <[email-masked]> wrote:

> Antone Roundy suggests:
> +1 make atom:author plural
> +1 keep atom:contributor
> € punt bylines to an extension
> 
> Again, +1 to Antone¹s suggestion.

+1,+1, and +1 from me too.

> I¹ve expressed an affinity for the idea of putting atom:category

seeing as that proposal was my idea, and despite no technical objections to
it, I'm happy to withdraw it just so atom:author can get through the process
hoops.

e.

---

From: Henry Story <[email-masked]>
Date: Mon, 23 May 2005 08:50:23 +0200

> • punt bylines to an extension

+1 to all
I think that makes sense, especially if one thinks that atom could
be used for wiki entries, where there being numerous authors is a
fact of daily life.

Henry

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 23 May 2005 09:01:26 +0200

> Again, +1 to Antone’s suggestion.

+1.

-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

---

From: Tim Bray <[email-masked]>
Date: Sun, 22 May 2005 21:52:53 -0700

<co-chair-mode>We observe a significant amount of discomfort with the  
current one-author/multiple-contributors model in atom-format.   
Despite the mentions that Rob dug up, nobody can claim this has had  
serious in-depth discussion in the IETF context.

On the other hand, we note that the current setup does have a  
coherent logical grounding, namely adopting Dublin Core semantics by  
identifying a singular primary-creator role and a plural contributor  
role.  If we leave things the way they are, a pointer to this  
derivation would improve the draft.

However, aside from Rob Sayre, nobody has been particularly militant  
in defending the current setup.  Personally I don't think any of the  
alternatives proposed are going to have fewer corner cases, but quite  
likely they won't have more either.

Unfortunately, among those who want to change the current setup, we  
do not observe consensus on the subject of what to change them to.   
Near as we can tell, people want to make atom:author plural, some  
want to nuke atom:contributor and others don't.

If, in the next couple of days, a large number of people can coalesce  
behind ONE SPECIFIC change to the spec in this area, and there is no  
significant body of resistance to this change, Paul and I are  
prepared to be convinced that rough consensus exists for such a  
change.</co-chair-mode>

---

From: David Powell <[email-masked]>
Date: Mon, 23 May 2005 08:36:00 +0100

Monday, May 23, 2005, 6:22:49 AM, A. Pagaltzis wrote:

>  make atom:author plural

+1 in principle...

But has anyone addressed how this will inherit - will
atom:entry/atom:author merge with the set of authors defined in
atom:feed/atom:author or will it replace them?

(FYI: PRISM also suggests using plural dc:creator elements when there
are multiple primary creators.)

>  keep atom:contributor

+1

(But we should clarify the inheritance rules - if there are any - to
avoid confusion with those of atom:author - if there any)

>  punt bylines to an extension

+1

(It could live happily with dateline, or whatever it gets called)

-- 
Dave

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 23 May 2005 10:19:39 +0200

> atom:feed/atom:author or will it replace them?

Merging is easy to express in terms of replacement: you simply
repeat the subset of shared authors.

Replacement is not expressible in terms of merging; we would need
a mechanism to indicate an deviation from merging semantics.
Merging would also be inherently slightly more complex to
implement in consumers, and would be additionally more complex to
implement because it requires support for whichever mechanism
indicates replacement. It could also require extra complexity to
support at the producer level.

So my opinion is clearly: replace. It’s simpler to specify,
simpler to implement, and it doesn’t lose any expressiveness.

Regards,
-- 
Aristotle

---

From: Dan Brickley <[email-masked]>
Date: Mon, 23 May 2005 05:56:18 -0400

* Eric Scheid <[email-masked]> [2005-05-23 15:48+1000]
> +1,+1, and +1 from me too.

+1, +1, +.5 from me

BTW, and aside re Dublin Core semantics, DC allows all DC terms to be 
repeated, including 'creator'; the definition is
given in http://dublincore.org/documents/dcmi-terms/
"An entity primarily responsible for making the content of the
resource." with the notes "Examples of a Creator include a person, an
organisation, or a service. Typically, the name of a Creator should be
used to indicate the entity.". It says 'an entity' rather than 'the 
entity'. 'Primarily' might suggest one rather than many, but the notion
of multiple entities being 'jointly first' in their responsibility for 
making the content seems to sneak us out of that one.  Dublin Core has 
a group on Agents, see http://dublincore.org/groups/agents/ 
...at the last Dublin Core Advisory Board meeting I said I'd try to get 
FOAF measured up against their functional requirements doc, 
http://rdfweb.org/pipermail/rdfweb-dev/2004-October/013820.html
...probably time to revisit that discussion.

Also worth noting in that regard is that there are different idioms for
deploying dc:creator (sometimes as a relationship to a string, sometimes
as a relationship to an Agent of some kind) in RDF; 
http://danbri.org/words/?p=63 was an experiment in making explicit rules
for mapping between them.

Dan

---

From: James Aylett <[email-masked]>
Date: Mon, 23 May 2005 11:42:00 +0100

> > > € punt bylines to an extension

+1, +.5, +.5 from me.

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  [email-masked]                               uncertaintydivision.org

---

From: Danny Ayers <[email-masked]>
Date: Mon, 23 May 2005 13:22:13 +0200

I'm not 100% convinced of the need for contributor, but in the
interests of consensus:

+1 make atom:author plural
+1 keep atom:contributor
+1 punt bylines to an extension

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 24 May 2005 01:02:51 +0200

I already voted but, for the record, I'm +1 on the three bullets.

David Powell wrote:

>>� make atom:author plural
>>    
>>
>
>+1 in principle...
>
+1 to replace

>>� keep atom:contributor
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...

-- 
Thomas Broyer

---

From: Eric Scheid <[email-masked]>
Date: Tue, 24 May 2005 09:31:49 +1000

> without at least an atom:author, though I'm not sure this wouldn't bring

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.

---

From: Graham <[email-masked]>
Date: Tue, 24 May 2005 00:56:58 +0100

> that inheritance draws first from atom:source (if it exists), and then

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

---

From: Eric Scheid <[email-masked]>
Date: Tue, 24 May 2005 10:02:16 +1000

On 24/5/05 9:56 AM, "Graham" <[email-masked]> 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
well spotted.

e.

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 24 May 2005 01:02:54 +0100

> 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

---

From: Robert Sayre <[email-masked]>
Date: Mon, 23 May 2005 20:36:50 -0400

> > (unrelated question: what's with this plus sign " & atomLink+" in the

That means "oneOrMore", while "*" means "zeroOrMore". "+" is accurate
for format-08, which requires an alternate link.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Tue, 24 May 2005 10:48:48 +1000

> 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 link[@rel=alternate] 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.

---

From: Walter Underwood <[email-masked]>
Date: Mon, 23 May 2005 17:59:04 -0700

--On May 24, 2005 1:02:54 AM +0100 Bill de hÓra <[email-masked]> wrote:
>
> Inheritance suggests a programming model to allow the evaluator to be coded for it.

Which is why it shouldn't be called "inheritance". I'd prefer something
like "cascading values".

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Robert Sayre <[email-masked]>
Date: Mon, 23 May 2005 21:23:49 -0400

"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-masked]> 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

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 24 May 2005 04:38:13 +0200

* Eric Scheid <[email-masked]> [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

---

From: Janne Jalkanen <[email-masked]>
Date: Tue, 24 May 2005 09:15:54 +0300

> he is fine with the proposal in that thread.

+1 from here too; works well for me.

/Janne

---

From: "Thomas Broyer" <[email-masked]>
Date: Tue, 24 May 2005 09:00:04 +0200 (CEST)

> 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?

> 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.

>     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

---

From: Henry Story <[email-masked]>
Date: Tue, 24 May 2005 09:52:07 +0200

Simplify, simplify. I am for removing all inheritance mechanisms...

Henry

On 24 May 2005, at 02:02, Bill de hÓra wrote:
> 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
>
>

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 24 May 2005 09:51:39 +0200

* Thomas Broyer <[email-masked]> [2005-05-24 09:05]:
> 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

---

From: Graham <[email-masked]>
Date: Tue, 24 May 2005 09:27:48 +0100

> guess we could add "All required feed metadata elements MUST be

I think the thing it's missing is "All elements MUST be copied when  
creating an atom:source from an atom:feed"

Graham

---

From: "Thomas Broyer" <[email-masked]>
Date: Tue, 24 May 2005 15:02:02 +0200 (CEST)

A. Pagaltzis wrote:
> * Thomas Broyer [2005-05-24 09:05]:
>> c)
>> feed:
>>   author: A
>>   contributor: B
>>   entry:
>>     contributor: C
[...]
>>    also open to considering it invalid.
[...]
>     atom:contributor may only appear if ../atom:author is also

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".

> 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.

> be symmetric to simplify specification and implementation.

-0 to forbidding contributors without author at the feed level.

-- 
Thomas Broyer

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 24 May 2005 15:19:46 +0200

> • punt bylines to an extension

It's the best suggestion made so far that has any potential of getting  
into the spec until christmas, so I'm +1 on this. :-)

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: Antone Roundy <[email-masked]>
Date: Tue, 24 May 2005 07:39:40 -0600

> 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].

>>> 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

---

From: "Thomas Broyer" <[email-masked]>
Date: Tue, 24 May 2005 17:09:47 +0200 (CEST)

> 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

---

From: Walter Underwood <[email-masked]>
Date: Tue, 24 May 2005 09:21:58 -0700

>> Simplify, simplify. I am for removing all inheritance mechanisms...

+1. Inheritance has very minor advantages and very serious disadvantages.

Inheriting values saves typing. It does not save bandwidth, because
HTTP compression will do nearly as well.

It is confusing and tricky to specify and implement. It makes the entry
different when it is standalone or in a feed. It multiplies the number
of test cases needed for validation.

Any one of those problems is serious.

wunder

---

From: Antone Roundy <[email-masked]>
Date: Tue, 24 May 2005 11:55:11 -0600

> HTTP compression will do nearly as well.

6% of the feeds I subscribe to use compression.  I don't think we can 
depend on that yet.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 25 May 2005 03:29:04 +0200

* Thomas Broyer <[email-masked]> [2005-05-24 15:15]:
> >> c) The entry inherits the author but overrides the
> >>    contributor. I'm also open to considering it invalid.
> [...]

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.
> 

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.

> 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

---

From: "Thomas Broyer" <[email-masked]>
Date: Wed, 25 May 2005 09:03:51 +0200 (CEST)

A. Pagaltzis wrote:
> * Thomas Broyer [2005-05-24 15:15]:
>> A. Pagaltzis wrote:
[...]
> That seems to allow entries with contributors, but no author. You

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.

> more code and more grammar rules. To me, that raises flags that

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:author><atom:name>...</atom:name></atom:author>
         ...
      </atom:source>
      ...
   </atom:entry>
</atom:feed>

-- 
Thomas Broyer