Subject: A different question about atom:author and inheritance

From: David Powell <[email-masked]>
Date: Sun, 22 May 2005 18:21:37 +0100

I am concerned that the requirement:

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

...suggests that some sort of inheritance goes on, but such a
mechanism isn't obvious and isn't described anywhere. Draft -06 had a
comment from Robert in there saying that inheritance needed
explaining, but I can't see where this issue was resolved.

Are these interpretations correct? They are personal opinions. Does
the spec back them up?

a)

<feed>
  <author><name>A</name></author>
  <entry>
  </entry>
</feed>

The author of the feed is "A". (perhaps in some editorial capacity)
The author of the entry is "A".

b)

<feed>
  <entry>
    <author><name>A</name></author>
  </entry>
</feed>

The author of the feed is undefined.
The author of the entry is "A".

c)

<feed>
  <entry>
    <source>
      <author><name>B</name></author>
    </source>
  </entry>
</feed>

The author of the feed is undefined.
The author of the entry is "B".
The author of the source feed is "B".

-- 
Dave

---

From: Robert Sayre <[email-masked]>
Date: Sun, 22 May 2005 13:53:43 -0400

> explaining, but I can't see where this issue was resolved.

The WG decided it wasn't worth specifying any more tightly. The
sentence you quoted states a cardinality requirement. Inheritance was
floated around, but the WG ultimately went with the language that's in
the draft. It forces you to have an author element in there somewhere,
but doesn't make logical assertions in the style of an RDF vocabulary.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Sun, 22 May 2005 14:04:41 -0400

> explaining, but I can't see where this issue was resolved.

Oops. Here's the discussion:
http://www.imc.org/atom-syntax/mail-archive/msg13793.html

Here's what the chairs said:
http://www.imc.org/atom-syntax/mail-archive/msg13784.html

I suppose we could drop some more of that proposed stuff in, but I
think the first bullet points of 4.1.1 and 4.1.2 cover it adequately.
Besides, no one indicated they were unhappy with that text in WG last
call or IETF last call.

Robert Sayre

---

From: David Powell <[email-masked]>
Date: Sun, 22 May 2005 21:01:43 +0100

> Besides, no one indicated they were unhappy with that text in WG last

Sorry, I was too busy reviewing the 23 additional Paces that were
proposed during IETF Last-Call to have time to sufficiently review the
specification itself.

We may of thought that we were finished, but it is clear that we were
not ready for Last-Call: neither the Working Group, nor the IETF had
sufficient time to review the specification because it has been in
flux with proposals.

Major changes such as PaceDuplicateIDs have been added and nobody has
seen the draft yet, let alone reviewed it.

The fact that both myself and the editor were confused about whether a
contentious paragraph had been accepted by the chairs, demonstrates
this problem. <http://www.imc.org/atom-syntax/mail-archive/msg15476.html>

-- 
Dave

---

From: David Powell <[email-masked]>
Date: Sun, 22 May 2005 21:01:37 +0100

> think the first bullet points of 4.1.1 and 4.1.2 cover it adequately.

Ok - it looks like my interpretations were wrong.  The spec doesn't
condone any kind of inheritance of atom:author from feeds to entries.
The requirement that either the feed or all entries contain
atom:author misled me.

So would these interpretations be correct:

a)

<feed>

The author of the feed is "A".
The author of the entry is undefined.

b)

<feed>
  <entry>

c)

<feed>
  <entry>
    <source>

The author of the feed is undefined.
The author of the entry is undefined.
The author of the source feed is "B".

I think that the current text is very misleading. The fact that at one
point inheritance has been condoned or suggested by previous drafts
(including the widely implemented pre-IETF public draft), but now we
have removed the suggestion, but kept the syntactic requirement
certainly got me. The fact that the draft conflates the author
(editor?) of the feed with the author of the entries increases the
confusion.

We should add language that specifically states that the value of
atom:feed/atom:author is not a shortcut for specifying
atom:entry/atom:author - if that is what we mean.

(Hopefully, the WG agree that this is the intended meaning of the
author element? It would be a hugely embarrassing to define a simple
element in a completely ambiguous way, when RSS2.0 is crystal clear on
the matter.)

-- 
Dave

---

From: Robert Sayre <[email-masked]>
Date: Sun, 22 May 2005 17:05:17 -0400

> sufficient time to review the specification because it has been in

You know, thinking more about this one, it makes me more irritated
than I already am. If it's less flux you desire, there's a very easy
way to make that happen. The chairs could simply declare paces which
revisit issues the group has already decided to be out of order. The
fact that they've tolerated yet more discussion on things like
atom:modified and archiving, which brought exactly zero bits of new
information to the discussion, speaks volumes about their patience. I
take a less diplomatic view of the past few days...

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Sun, 22 May 2005 17:25:29 -0400

On 5/22/05, David Powell <[email-masked]> wrote:
> certainly got me. 

So, are you saying that we're required to explicitly reverse any
requirement present in previous drafts?

> The fact that the draft conflates the author

Where does the draft conflate the two?

Robert Sayre

---

From: David Powell <[email-masked]>
Date: Sun, 22 May 2005 22:57:03 +0100

> requirement present in previous drafts?

No, we're required to state the situation one way or the other. The
current draft doesn't say that author is inherited, so I assumed that
my original interpretation was incorrect.

If it is intended to be inherited, can we still add text saying that
it is inherited as an editorial change?

> Where does the draft conflate the two?

Given this feed, how should it be displayed by an implementation?

<feed xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-08">
  <author>
    <name>David Powell</name>
  </author>
  <title>An example feed</title>
  <updated>2005-05-22T21:35:00Z</updated>
  <link rel="alternate" href="http://example.com/feeduri" />
  <entry>
    <id>http://example.com/entries/1</id>
    <title>Who wrote this?</title>
    <content type="text">The content should go here...</content>
    <updated>2005-05-22T21:35:00Z</updated>
  </entry>
</feed>

Is this correct:

> Who wrote this?
> ===============
> 
> The content should go here...
> 
> Last updated: 22nd May 2005 by David Powell

Or was "David Powell" only intended to be the author (editor?) of the
feed, and has the entry therefore been mis-attributed?

-- 
Dave

---

From: Robert Sayre <[email-masked]>
Date: Sun, 22 May 2005 18:10:49 -0400

> it is inherited as an editorial change?

We can clarify and improve the draft to your heart's delight. It's
unproductively revisiting old arguments that bothers me. :)

> Given this feed, how should it be displayed by an implementation?

My problem is that the draft (wisely) doesn't make requirements about
what implementations should 'display'. Shrook and PubSub.com are both
'implementations' and both may or may not 'display' authors, either of
a feed or an entry.

Here is the code that determines what to put in the "From" field when
Thunderbird parses an RSS2 feed:

item.author = getNodeValue(itemNode.getElementsByTagName("author")[0]
                                  ||
itemNode.getElementsByTagName("creator")[0])
                                  || aFeed.title
                                  || item.author;

That's not particularly sophisticated. I think the author of that code
assumed finding the author would be Really Simple. Are you suggesting
we can specify what that code should do, briefly, usefully, and
clearly? If so, let's hear it. My personal opinion is that the best
way for publishers to ensure their preferred text is displayed is to
put an author element in the atom:entry. Of course, code like the
stuff above wouldn't pick up multiple atom:author elements (just
thought I'd mix it up :)

Robert Sayre

---

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

> unproductively revisiting old arguments that bothers me. :)

Yeah, I was startled just now to realize that there's nothing there  
to say that the feed-level author applies to entry-level when it's  
not specified at the entry level.  The intent seems pretty clear;  
entry-level overrides source-level overrides feed-level, but it seems  
like we should say that.

Anybody think this is anything more than an editorial change? -Tim

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 23 May 2005 00:10:04 +0100

> Anybody think this is anything more than an editorial change? -Tim

Not me (you'd have to tell me that inheritance applies at all, not the 
other way around). But the rules must be consistent for the elements 
that appear at both levels.

cheers
Bill

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 22 May 2005 19:20:21 -0400

Tim Bray wrote:
>The intent seems pretty clear; entry-level overrides source-level 
> overrides feed-level, but it seems like we should say that.
	I believe that this three-level chain of inheritance has always been
what we've intended. There was, however, a great deal of discussion at one
point about how to actually write the words. Thus, I agree that it is
largely an editorial change; however, you might expect some controversy over
particular word choices. Give it a shot and let's see how folk respond.

	Note: There is more to authorship than just the inheritance issue. I
think it also makes sense that a "feed-level author" should be considered to
be the author of the collection of items which is the feed. This authorship
is independent of authorship over any particular entry within the feed. Even
if the feed contains no items authored by the feed-level author, the
feed-level author is still author of the collection. This distinction would
be useful in describing linkblogs, and a variety of other feeds types that
are composed of entries collected from other feeds or multiple authors.

		bob wyman

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 23 May 2005 00:18:58 +0100

> that appear at both levels.

Quick followup: I'll take an action to review the upcoming format draft 
to see if we need to apply any such wording to feed level extensions.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Sun, 22 May 2005 19:34:29 -0400

On 5/22/05, Bob Wyman <[email-masked]> wrote:
> largely an editorial change; 

Fully agree.

Robert Sayre

---

From: David Powell <[email-masked]>
Date: Mon, 23 May 2005 01:01:16 +0100

> particular word choices. Give it a shot and let's see how folk respond.

+1

> are composed of entries collected from other feeds or multiple authors.

+1

I think it would be best if we stated both of these effects close
together in the specification so that it is obvious what the effect of
providing atom:feed/atom:author is.

We should also do a check on:

atom:feed/atom:category
atom:feed/atom:contributor
atom:feed/atom:copyright

to make sure that we are as clear as possible about whether or not
they are inherited by entries, and whether or not they apply to the
feed as a itself.

-- 
Dave

---

From: Eric Scheid <[email-masked]>
Date: Mon, 23 May 2005 11:39:54 +1000

> atom:entry/atom:author - if that is what we mean.

+1 for disambiguating either way.

e.

---

From: Robert Sayre <[email-masked]>
Date: Sun, 22 May 2005 16:53:23 -0400

> sufficient time to review the specification because it has been in

I can't agree with that statement. The draft hasn't changed for more
than a month, while Tim and Paul have been last-calling this thing for
months now, and very little of substance has transpired since then.
The document has been quite stable since March 12th, when format-06
was produced.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Mon, 23 May 2005 12:00:09 +1000

> Anybody think this is anything more than an editorial change? -Tim

I don't think we ever decided AGAINST inheritance, we only punted on
explaining it. Thus, I've assumed that inheritance was implied. That reading
the spec in isolation is ambiguous makes it a bad spec.

We don't need a Pace, this is an editorial change.

The editor might insist on camera ready copy though -- I hear he's a bit
curmudgeonly lately.

e.

---

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

Sunday, May 22, 2005, 9:53:23 PM, Robert Sayre wrote:

> The draft hasn't changed for more than a month, while Tim and Paul
> have been last-calling this thing for months now, and very little of
> substance has transpired since then. The document has been quite
> stable since March 12th, when format-06 was produced.

No, the draft hasn't changed in the last month, but it will do when
draft-09 is released.

I was talking about the batch of proposals, including
PaceAllowDuplicateIDs (a fundamental change), that were accepted 4
days ago. <http://www.imc.org/atom-syntax/mail-archive/msg15289.html>

-- 
Dave