Subject: Fetch me an author. Now, fetch me another author.

From: Bill de hÓra <[email-masked]>
Date: Fri, 20 May 2005 19:29:34 +0100

http://www.franklinmint.fm/blog/archives/000393.html

"The Atom author element may be inadequate for scientific journals, 
legal documents, and legislation. I am shocked, just shocked."

Translation: The Atom format mandates you can only have one author, for 
an entry or a feed.

Why is this not a spec bug? Can anyone point to consensus on this decision?

cheers
Bill

---

From: Graham <[email-masked]>
Date: Sat, 21 May 2005 12:14:09 +0100

On 21 May 2005, at 1:59 am, Tim Bray wrote:

> Let me speak as a victim of a few years in the publishing-software  
> trenches: The semantics of author and contributor are a tangled  
> mess, a real swamp, and I don't think that Atom is going to do a  
> very good job of solving them.  In particular, I don't think we're  
> going to a better job than Dublin Core.

Why are we using "author" instead of "creator" then? The current  
setup is a rushed kludge that came about before we started thinking  
things through, not a conscious decision to echo Dublin Core.

> That is to say, if we were to do as some suggest (nuke  
> atom:contributor and make atom:author repeatable) I'm quite certain  
> that we could come up with all sorts of corner cases and problems,  
> probably about as many as with the current setup.

You can say that about anything. A flat list of people associated  
with an entry is infinitely better than the weird one author/multiple  
contributors model that doesn't offer a clear way to cope with the  
common model of multiple co-authors.

Graham

---

From: Tim Bray <[email-masked]>
Date: Fri, 20 May 2005 17:59:03 -0700

On May 20, 2005, at 11:29 AM, Bill de hÓra wrote:

> Translation: The Atom format mandates you can only have one author, 
> for an entry or a feed.
>

A scan of the archives reveals no discussion; i.e. this rule is 
something that predates the move to the IETF.  I believe that (with a 
bit of offline help) I can explain the reasoning though.  We were 
trying to borrow the Dublin Core semantics, wherein there is the notion 
of an "Entity Primarily Responsible", dc:creator.  So, Atom gives you 
that with atom:author and the notion of a contributor in 
atom:contributor.

Let me speak as a victim of a few years in the publishing-software 
trenches: The semantics of author and contributor are a tangled mess, a 
real swamp, and I don't think that Atom is going to do a very good job 
of solving them.  In particular, I don't think we're going to a better 
job than Dublin Core.  That is to say, if we were to do as some suggest 
(nuke atom:contributor and make atom:author repeatable) I'm quite 
certain that we could come up with all sorts of corner cases and 
problems, probably about as many as with the current setup.

So, bearing that in mind, and also bearing in mind Paul's recent essay 
on process, I'm strongly -1 on any change whatsoever to the current 
definition of author and contributor. -Tim

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 21 May 2005 11:07:15 +0100

Tim Bray wrote:

> bit of offline help) I can explain the reasoning though.  We were trying 
> to borrow the Dublin Core semantics, wherein there is the notion of an 
> "Entity Primarily Responsible", dc:creator.  So, Atom gives you that 
> with atom:author and the notion of a contributor in atom:contributor.

I also scanned the archives and found no consensus.

> problems, probably about as many as with the current setup.

I observe this is one of the problems with borrowing semantics without 
attribution and without consultation. You might be quite certain, but 
the fact is we don't know.

> definition of author and contributor. -Tim

As co-chair, please instruct the editors to add spec text mentioning 
this rationale, it is hardly satisfactory to have that constraint in 
there as it stands.

It's tempting now to perform due diligence, and go through every 
constraint in the spec and cross-reference consensus.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 10:11:56 -0400

> common model of multiple co-authors.

Ben Lund is okay with the current draft:
http://www.imc.org/atom-syntax/mail-archive/msg15380.html

Why aren't you?

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 10:09:58 -0400

> I also scanned the archives and found no consensus.

I can point you to many discussions surrounding atom:author. Here's one:
http://www.imc.org/atom-syntax/mail-archive/msg13793.html

The requirement made it through nine drafts, much discussion, and two
last calls. I don't think you have a consensus argument.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Sat, 21 May 2005 15:25:58 +0100

> http://www.imc.org/atom-syntax/mail-archive/msg15380.html

Because what you presented to him makes no sense against the current  
draft. Two problems:
- The first is that atom:author is referenced in the singular  
throughout. I think it's a stretch to say "Yuri Fialko, David  
Sandwell, Mark Simons &amp; Paul Rosen" is a "person, corporation, or  
similar entity". I'm not saying it's wrong, but the current wording  
is inadequate and/or misleading with regards to your usage.

2nd problem:
Let's say I write an entry, but a couple of my friends contribute  
some material (abbreviated syntax):
<entry>
  <author>Graham</author>
  <contributor>Friend 1</contributor>
  <contributor>Friend 2</contributor>
</entry>

The appropriate way to decode this is "Written by Graham with  
contributions from Friend 1 and Friend 2"

Lets decode your sample in the same way: "Written by Yuri Fialko,  
David Sandwell, Mark Simons & Paul Rosen with contributions from Yuri  
Fialko, David Sandwell, Mark Simons and Paul Rosen"

Which makes no sense. The two usages are incompatible, and the spec  
needs to say which is correct.

Graham

---

From: Graham <[email-masked]>
Date: Sat, 21 May 2005 15:38:32 +0100

On 21 May 2005, at 3:30 pm, Robert Sayre wrote:

> What makes you think 'authorship' is arrived at by composing
> atom:author and atom:contributor elements.

It's the impression I've had for nearly 2 years. If I'm wrong, then  
fine, but there's nothing in the spec that says anything either way.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 11:02:08 -0400

> fine, but there's nothing in the spec that says anything either way.

Well, there's nothing in the spec that explicitly separates
atom:author from lots of elements. Your impression is not in the spec.
I do think you're right about the wording of atom:author, though.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 21 May 2005 16:03:05 +0100

Robert Sayre wrote:
> I can point you to many discussions surrounding atom:author. 

Thanks for the offer, but I've already done that for myself. I don't 
much care for the number of discussions, I care about this specification 
and whether it has consensus. Can you find one discussion that addresses 
  cardinality? Most of the ones I saw when I grepped through the 
archives seemed to focus on feed/entry inheritance.

> Here's one:

If you don't think I have a consensus argument, you should be able to 
demonstrate that by pointing me at consensus.

Look. I understand the process more or less says we're done, I read 
Paul's mail, and as the editor I do appreciate your sentiments and 
opinion on this.

If there is consensus and I missed it, I'll withdraw and apologise for 
distracting the WG. If an IETF process wizard says it's too late now, 
technically or in the spirit of things, I'll withdraw. If the WG makes 
it known that at this point in the process, I have to like them apples, 
  we're shipping, I'll withdraw. Otherwise as a WG member I'm of the 
opinion that letting a specification get through that has no consensus, 
and that we know has no consensus, is irresponsible.

cheers
Bill

---

From: Graham <[email-masked]>
Date: Sat, 21 May 2005 16:11:45 +0100

> atom:author from lots of elements. Your impression is not in the spec.

I just about grasp what you're saying here. I certainly do not think  
it's the obvious model from the spec, or an obvious model to most  
people.

> I do think you're right about the wording of atom:author, though.

Good.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Sun, 22 May 2005 01:16:25 +1000

On 22/5/05 12:25 AM, "Graham" <[email-masked]> wrote:

> draft.  
> [...]

what if <author> in that example was renamed to <byline> (and specced to be
something other than a Person Construct), and some mechanism introduced to
indicate the nature of the contribution by each of the <contributor>s?

using that model (in that message) without renaming the <author> element
will only be confusing.

e.

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 11:23:03 -0400

> and that we know has no consensus, is irresponsible.

Well, this is all process bullshit. What is the technical problem?
What document is impossible to express with the current syntax?

Robert Sayre

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 21 May 2005 18:19:51 +0200

* Eric Scheid <[email-masked]> [2005-05-21 17:30]:
> what if <author> in that example was renamed to <byline> (and
> specced to be something other than a Person Construct),

+1, calling it “author” when that sort of usage is expected and
encouraged is a lie.

> and some mechanism introduced to indicate the nature of the
> contribution by each of the <contributor>s?

Allowing atom:category would be nice, though I think we can punt
on that.

Regards,
-- 
Aristotle

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 12:51:03 -0400

> > specced to be something other than a Person Construct),

What are you talking about? Please refrain from complaining your pet
semantics aren't in the draft. Here are some simple questions, which
you can answer by reading the example I gave, and reading the draft.

Who is the author of that entry?
Who are the contributors?

There is no mention of 'byline'. You are complaining that you can't
have multiple 'authors' for some definition of 'author', because of
element cardinality. I observe that Ben Lund's example, with multiple
dc:creator elements, was a failure. Multiple author elements failed
the science journal use case, the basis of your original objection.
format-08 works.

I fully agree that other ways of arranging authors and contributors
are possible and reasonable, but no one has demonstrated a document
that format-08 can't cover. At this stage, changing the spec to suit
religious preferences would be extremely arrogant.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Sun, 22 May 2005 03:24:14 +1000

> semantics aren't in the draft.

It wasn't a complaint, it was a suggestion, and it was directed more to
Graham than to you.

Here's a free cluepon: "what if [...]"

> Here are some simple questions, which

The problem with the example you gave is that it suggests that even entries
with just the one author/contributor would need two person constructs in the
entry, or maybe just the one ... either way it's confusing.

Also, more importantly, how do you then indicate which individuals listed as
<contributor> have an <author> credit and which individuals were only
<contributor>s.

Consider this example (and please note that the second line isn't the
literal bits on the wire):

<entry>
    <author><name>##### a list of THREE names #####</name></author>
    <contributor><name>Bob Bellows</name><uri>B.html</uri></contributor>
    <contributor><name>Fred Fellows</name><uri>F.html</uri></contributor>
    <contributor><name>Jon Jello</name><uri>J.html</uri></contributor>
    <contributor><name>Ada Aiello</name><uri>A.html</uri></contributor>
    [...]
</entry>

Now, this *is* a valid format-08 document, right? BUT can you tell me who
the THREE authors are, and who the fourth person is who is only a
contributor (and not an author)?

So: valid format-08, but junk data.

> There is no mention of 'byline'.

There most certainly is a mention of the thing I have referred to elsewhere
as a "byline". It happens to be serialised within <author><name>. Instead of
the literal element name "byline" I could just as easily use the literal
element name of "authorship".

> format-08 works.

for some definition of "works" ... like "passes the validator", but not
"provides meaningful semantics".

> that format-08 can't cover.

can we shoe-horn data into elements? sure.
would that document then pass the validator? sure
can we extract that data in a meaningful sense? no.

> At this stage, changing the spec to suit

Oh, please, stop trolling.

e.

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 13:38:34 -0400

> entry, or maybe just the one ... either way it's confusing.

No, it doesn't. Why are you saying it suggests that? There are two
questions and two answers. I don't see a problem.

> <contributor> have an <author> credit and which individuals were only

Why are you mapping elements to types of credit? There is nothing in
the spec that suggests they map to types of credit. As I said, please
read the draft.

> contributor (and not an author)?

No. Why do you think that's a requirement? Couldn't you add an
extension to differentiate them?

> Oh, please, stop trolling.

Seriously, 2 more months of this crap to solve a 'problem' which you
can't give an example of. You might have a perfect spec, but no one
will care if it is never done.

Robert Sayre

---

From: Thomas Broyer <[email-masked]>
Date: Sat, 21 May 2005 20:37:21 +0200

>that format-08 can't cover.
The Atom Syndication Fformat spec has two authors and many contributors. 
Limiting to one author, you can't distinguish between the authors and 
contributors.

+1 on allowing multiple atom:author
-1 to dropping atom:contributor
-1 to renaming atom:author
(I did already say I was +1 on having deterministic content model and 
according care to element ordering but that's not really the point here)

<atom:entry>
   <atom:title>The Atom Syndication Format</atom:title>
   <atom:subtitle>draft-ietf-atompub-format-08</atom:subtitle>
   <atom:author>
      <atom:name>Mark Nottingham</atom:name>
      <atom:email>[email-masked]</atom:email>
      <atom:uri>http://www.mnot.net/</atom:uri>
   </atom:author>
   <atom:author>
      <atom:name>Robert Sayre</atom:name>
      <atom:email>[email-masked]</atom:email>
      <atom:uri>http://boswijck.com</atom:uri>
   </atom:author>
   <atom:contributor>
      <atom:name>Tim Bray</atom:name>
   </atom:contributor>
   <atom:contributor>
      <atom:name>Mark Pilgrim</atom:name>
   </atom:contributor>
   <atom:contributor>
      <atom:name>Sam Ruby</atom:name>
   </atom:contributor>
   <atom:contributor>
      <atom:name>Norman Walsh</atom:name>
   </atom:contributor>
   <atom:content 
src="http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt" 
/>
</atom:entry>

-- 
Thomas Broyer

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 21 May 2005 20:45:50 +0200

* Robert Sayre <[email-masked]> [2005-05-21 19:05]:
> At this stage, changing the spec to suit religious preferences
> would be extremely arrogant.

Please stop talking to people about “process bullshit” at one
occasion and turning around to chide others for “at this stage”
at the next.

Regards,
-- 
Aristotle

---

From: Anne van Kesteren <[email-masked]>
Date: Sat, 21 May 2005 20:46:17 +0200

> -1 to renaming atom:author

+1 to that.

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

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 15:13:13 -0400

On 5/21/05, A. Pagaltzis <[email-masked]> wrote:
> Please stop talking to people about "process bullshit" at one
> occasion and turning around to chide others for "at this stage"
> at the next.

As I said before, it doesn't matter if the spec is perfect if it takes
forever. Making up requirements after last call is out of order. Eric
is making up requirements and adding category elements to author
elements. It is beyond ridiculous.

Pardon me if I'm getting impatient, but I don't think any of the ideas
raised in the past few days are critical improvements to the format.
In fact, all I see is people twiddling their beanies about semantics,
rather than explaining why they need X for their products (Wyman
excluded--note that he raised his atom:id issue in last call). Bob's
bits-on-the-wire approach to multiple ids is fine. We can put the DOS
issue in the security concerns, but it really comes down to "don't
believe everything you read on the internet". The current suggested
text makes the terrible mistake of conflating atom:id and timestamps.

I remember Graham once tried to re-raise the atom:modified idea, and
was told that he was very close to being out-of-order. Well, it
certainly is now. Not only is it offensive, but there's no reason to
expect it will work, and no reason it couldn't be added if it does
happen to work. So, really, we have folks who want to delay this spec
because they think they've solved Distributed Versioning On The
Internet.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Sun, 22 May 2005 05:16:39 +1000

>> -1 to renaming atom:author

I'm +0.5 to all that ... the sticky problem is just how do we insert an
authorship string like "Raggett, D, Hors, A, and I Jacobs" into an entry,
and I'm -1 on using an extension for that since there is a $17 billion
industry already using feeds that really wants to be able to insert that
kind of authorship string.

No, we can't put that inside <author> for reasons I'll explain in a moment.

e.

---

From: Thomas Broyer <[email-masked]>
Date: Sat, 21 May 2005 21:34:27 +0200

>kind of authorship string.
You don't, but it can be built from multiple atom:author elements:

<atom:author><atom:name>Ragget, D</atom:name></atom:author>
<atom:author><atom:name>Hors, A</atom:name></atom:author>
<atom:author><atom:name>I Jaccobs</atom:name></atom:author>

...but we might need atom:author elements to be ordered...

-- 
Thomas Broyer

---

From: Eric Scheid <[email-masked]>
Date: Sun, 22 May 2005 05:49:47 +1000

On 22/5/05 5:13 AM, "Robert Sayre" <[email-masked]> wrote:

> Making up requirements after last call is out of order.

Not so...

Paul Hoffman wrote:
> New issues for the format spec are now being brought up, issues that
> existed *before* the WG Last Call, much less the IETF-wide Last Call.
> The IETF process allows for this.

Read that last line again.

e.

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 16:00:12 -0400

On 5/21/05, Phil Ringnalda <[email-masked]> wrote:
> Actually, no. It has one author, a "corporation, or similar entity," the
> ATOMPUB Working Group, and two editors and many contributors. (Editorial
> nit: -08 says it's a product of the Network Working Group, apparently
> the xml2rfc default for <workgroup>).

http://www.rfc-editor.org/rfcfaq.html

2) Every RFC is attributed to the "Network Working Group". What
working group is that?

    This label in the heading of every RFC is historical in form and
symbolic in content. Historically, "network working group" meant the
set of researchers who developed the packet switching protocols for
the ARPAnet, beginning in 1969. This label is maintained on RFCs as a
reminder of the long and significant technical history that is
recorded in the RFC series, and as a reminder that today's technical
decisions, wise or not, may be with us for many years. Today, the
"Network Working Group" should be interpreted as the set of users,
vendors, and researchers who are working to improve and extend the
Internet, in particular under the ISOC/IETF umbrella.

------

Of course, the entity primarily responsible for the draft is the IETF,
and the internet community.

A theory: no one who thought IETF last call meant we were done is
reading the list anymore, so all we have left are people intent on
descending every rathole and continuing to work on the spec until it
becomes a suitably ornate design-by-committee monster.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 16:03:49 -0400

> Read that last line again.

Paul and Tim are the ones that decide what is out of order. I am just
stating my opinion, which is that more work on the format spec is a
waste of time.

Robert Sayre

---

From: Phil Ringnalda <[email-masked]>
Date: Sat, 21 May 2005 13:22:38 -0700

Robert Sayre wrote:
> 2) Every RFC is attributed to the "Network Working Group".

Bah. I was confused by the way some WGs list themselves while it's still 
an I-D, and some don't. I'll go back to my corner now.

Phil Ringnalda

---

From: David Powell <[email-masked]>
Date: Sat, 21 May 2005 22:53:50 +0100

Saturday, May 21, 2005, 8:13:13 PM, Robert Sayre wrote:

> So, really, we have folks who want to delay this spec

This is a straw man argument.

PaceDateModified2 was created to allow subscribers to determine the
latest revision of an entry within a feed document.

Please explain the specific issues that you believe will prevent
PaceDateModified2 from meeting its goal. Tim gave some specific issues
he had with atom:modified and I addressed them. I need something more
than "there's no reason to expect it will work".

If the proposal is as doomed as you suggest, then we will be able to
drop this quickly and move on. Currently we seem to be just wasting
time.

> certainly is now. Not only is it offensive, 

I proposed PaceAllowDuplicateIdsWithModified/PaceDateModified2 to fix
a bug in PaceAllowDuplicateIDs, not to add a feature.

PaceAllowDuplicateIDs is a major change to Atom. The fact that it was
proposed after IETF Last Call suggests that we already had a process
problem. The fact that issues have been raised with this proposal, but
the debate has been curtailed on proposals to fix it suggests to me
that we need another round to clear this up.

-- 
Dave

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 18:08:50 -0400

> This is a straw man argument.

No, it isn't. You think you'll be able to disambiguate entries by
adding a more-specific date field, making for two date fields. I think
you can disambiguate entries by adding any number of extension fields.
That's great. Add extensions.

> than "there's no reason to expect it will work".

The WG disposed of this long ago because atom:modified cannot be
operationally distinguished from atom:updated. Obviously, if people
start shipping feeds with the same id and atom:updated figure, it will
be needed. There's no reason to standardize it, though. We don't know
how that would work. So, I can see the rationale for allowing
duplicate IDs. Hey, you never know.

> a bug in PaceAllowDuplicateIDs, not to add a feature.

Read Bob's email. atom:modified doesn't help with revisions. Why are
timestamps and atom:id related?

> problem. 

No, WGs deal with issues raised in last call. That's completely appropriate. 

> The fact that issues have been raised with this proposal, but

No, it suggests that someone who hasn't read the previous WG
discussion is proposing atom:modified Yet Again.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Sun, 22 May 2005 08:24:08 +1000

On 22/5/05 3:38 AM, "Robert Sayre" <[email-masked]> wrote:
> No, it doesn't. Why are you saying it suggests that?

OK, answer me this: if an entry has only one person associated with it, do
we write it with just a lone <author> element, or do we write it with an
<author> element *and* a <contributor> element?

What if there was one person who wrote the text, and two people who provided
suggestions or feedback or research (etc) but did not write any of the text,
and the publisher wishes to acknowledge their valuable input ... one
<author> and two <contributor>s, or one <author> and three <contributor>s?

>> Also, more importantly, how do you then indicate which individuals listed
>> as <contributor> have an <author> credit and which individuals were only
>> <contributor>s.
> 
> Why are you mapping elements to types of credit?

Are you seriously playing these word games for the sheer hell of it?

Let me try rephrasing to something more literal:

    how do you then indicate which individuals listed as a
    <contributor> could be referred to as an "author", and
    which individuals are "contributors" but not "author"?

> There is nothing in the spec that suggests they map to types of credit.
> As I said, please read the draft.

bullshit. format-08 says:

    The "atom:author" element is a Person construct that
    indicates the author of the entry or feed.
                  ^^^^^^^^^

and

    The "atom:contributor" element is a Person construct that indicates a
    person or other entity who contributed to the entry or feed.
                               ^^^^^^^^^^^^^^

Now, unless you can point to the place in the spec which re-defines those
two words in the English language, then we must assume they mean what they
commonly mean. They *don't* mean the same thing.

The *don't* mean the same thing. If they did, we wouldn't need two elements,
now would we?

> can't give an example of.

I've previously given examples in a round a bout way. Let me be more
explicit for you then:

    Publish an entry which indicates multiple people who are to be known as
an "author" of the entry, and distinguish them from some number of persons
who are to be known as a "contributor" to the entry (while not actually
being "authors"). Their "contributions" might be background research, for
example. Refer to sections 4.2.1 and 4.2.3 for the meanings of "author" and
"contributor".

> You might have a perfect spec, but no one will care if it is never done.

I'm not looking for a perfect spec. I'm hoping for a *useful* spec, one
applicable to some very real real-world use cases. Getting a feed document
to validate is nice, but it's not the end goal -- we must be able to
*extract* the data meaningfully.

e.

---

From: Antone Roundy <[email-masked]>
Date: Sat, 21 May 2005 16:48:07 -0600

On Saturday, May 21, 2005, at 04:08  PM, Robert Sayre wrote:
> You think you'll be able to disambiguate entries by
+1 -- those who need this can use an extension. Those who either don't 
publish multiple instances of entries with the same atom:updated in the 
same document or don't care about the ordering among those don't have 
to bother with it.  I'm a little uncomfortable with the idea of 
introducing a date/time element whose purpose is to convey a sequence 
rather than a timestamp.  It feels like major overkill with respect to 
what the data really means, which makes me think it's not the right 
solution.

Besides, I want to get Atom 1.0 finished.

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 21 May 2005 19:01:01 -0400

Robert Sayre wrote:
> atom:modified cannot be operationally distinguished from atom:updated.
> Obviously, if people start shipping feeds with the same id and
> atom:updated figure, it will be needed. There's no reason to
> standardize it, though. We don't know how that would work.
	The definition of atom:updated was explicitly and intentionally
crafted to permit the creation of multiple non-identical entries that shared
common atom:id and atom:updated values. Clearly, it was the intention of the
Working Group to permit this, otherwise the definition of atom:updated would
not be as it is. Thus, it is ridiculous to try to suggest that "feeds with
the same id and atom:updated" are somehow unanticipated or not-understood.
If such feeds are so far outside the ken of what the working group intends,
then atom:updated should never have been defined as it is.
	Additionally, atom:modified is clearly distinguished from
atom:updated *by definition!* Atom:modified indicates that last time an
entry was modified. Atom:updated indicates the last time it was modified in
a way that the publisher considered "significant." This is a very clear
distinction.

	bob wyman

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 19:08:47 -0400

> a way that the publisher considered "significant." This is a very clear

Bob, that's exactly right. The definitions are very different, and
this is not an issue that arises with the allowance for multiple
atom:ids in one feed document.

Here's the last time this discussion happened:
http://www.imc.org/atom-syntax/mail-archive/msg13276.html

Robert Sayre

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 21 May 2005 19:57:17 -0400

> http://www.imc.org/atom-syntax/mail-archive/msg13276.html
	Tim's point in the referenced mail supported the current definition
of atom:updated which provides a means for publishers to express their own
subjective opinions of what is a "significant" change to an entry. However,
the solution of one problem does not eliminate the second problem. The
second problem is that readers (not publishers) need to be able to
distinguish and temporally order entries that have been written by
publishers. Because the publishers CANNOT know the detailed needs of all
their readers, publishers' subjective input cannot be held to be useful.
Objective metrics which can be clearly understood by both publishers and
readers must be used. In this case, the best objective measure to use is to
say that the change of one of more bits in the encoding or representation of
an entry should result in a new atom:modified value.

	* Atom:updated addresses needs of publishers
	* Atom:modified addresses needs of readers

	Both sets of needs, that of publishers as well as readers, must be
addressed and dealt with by the Atom format. Atom:updated only addresses the
needs of publishers.

		bob wyman

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 20:05:28 -0400

> addressed and dealt with by the Atom format. Atom:updated only addresses the

The WG rejected 'objective dates' with prejudice.

I'm reminded of this discussion:
http://www.imc.org/atom-syntax/mail-archive/msg10954.html

You know, the one where we rejected atom:modified after considering
all of the same issues we're discussing now.

Robert Sayre

---

From: Phil Ringnalda <[email-masked]>
Date: Sat, 21 May 2005 12:52:02 -0700

Phil Ringnalda

---

From: Antone Roundy <[email-masked]>
Date: Sat, 21 May 2005 20:46:19 -0600

On Saturday, May 21, 2005, at 05:57  PM, Bob Wyman wrote:
> The
> publishers.

We may not have been discussing exactly the same details before, but 
when atom:modified was rejected before, I think the WG was saying that 
either readers don't "need" to be able to do things like this this, or 
that the "need" wasn't great enough to warrant creation of 
atom:modified.  We didn't all agree then, and we don't all agree now.  
Unless the "need" for this can be shown, and it can be shown that an 
extension can't take care of it, I'm -1 on atom:modified.

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 21 May 2005 23:20:03 -0400

Antone Roundy wrote:
> Unless the "need" for this can be shown, and it can be shown that
> an extension can't take care of it, I'm -1 on atom:modified.
	The need is simple and I've stated it dozens of times... Given two
non-identical entries that share the same atom:id and the same atom:updated,
I need to know which of them is to be presented to the user. The current
specification doesn't allow me to do anything other than make a random
choice. This is not reasonable. Atom:modified would provide the data needed
to determine which was the most recently produced of the two entries. That
most recently produced entry is the one that is most often desired by users.
	On extensions... Virtually anything can be done in extensions. If
nothing should be in the core except those things that can be defined by
extensions, then nothing would be in the core. It is inevitable that
extensions will not be as broadly implemented as elements of the core. The
practical implication of forcing something to be an extension is to ensure
that it is never broadly implemented.

		bob wyman

---

From: Antone Roundy <[email-masked]>
Date: Sat, 21 May 2005 21:36:58 -0600

On Saturday, May 21, 2005, at 09:20  PM, Bob Wyman wrote:
> 	The need is simple and I've stated it dozens of times...
...but is it a need or a want?  That was the point "need" in quotes was 
attempting to make.  I agree it is preferred to be able to reliably 
pick the last one, but I disagree that it's a particularly important 
preference.

Common practice is, and will probably continue to be, to include only 
one instance of a particular entry in a particular feed document.  Only 
in the unusual cases will there be any difficulty in determining which 
instance came last.

> 	On extensions... Virtually anything can be done in extensions.
Many things can, but not all.  An extension can't say "I'm not going to 
publish a title, because I have roundy:title++, which is better".  
atom:title is required.  Also, an extension won't be able to allow 
multiple atom:author elements if we don't amend the spec to allow them. 
  It will be able to define an alternative way of expressing authorship, 
and allow multiple of those, but a single author will continue to be 
required, either at the feed level or in the entry.  What I meant was 
"particularly without duplicating the function of a core element", 
which just makes things sloppy.

> It is inevitable that
It makes it more rare, certainly, but there are extensions which are 
broadly implemented, and I'm sure there will be more, if the need is 
significant enough to enough people.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 22 May 2005 05:55:15 +0200

* Robert Sayre <[email-masked]> [2005-05-21 21:25]:
> > > At this stage, changing the spec to suit religious
> > > preferences would be extremely arrogant.
> > 
> > occasion and turning around to chide others for "at this
> > stage" at the next.
> 
> As I said before, it doesn't matter if the spec is perfect if
> it takes forever. […]
> 
> Pardon me if I'm getting impatient, but I don't think any of
> the ideas raised in the past few days are critical improvements
> to the format. […]
> 
> I remember Graham once tried to re-raise the atom:modified
> idea, […]

And all of these of these are good points, but none of this is
what I’m talking about. What I’m talking about is is merely that
you keep using the process argument in whichever way will most
likely lead to the result you’re in favour of. It’s irritating
and detracts from your factual arguments, which are consistent.

That is all.

Regards,
-- 
Aristotle

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 22 May 2005 00:07:13 -0400

Antone Roundy wrote:
> Only in the unusual cases will there be any difficulty in determining
> which instance came last.
	"Unusual" is a relative term... I read over 10 million feeds every
day, many of them multiple times each day. I intend to read every public
feed that gets created. Thus, I'll be reading at least 100 million feeds by
the end of this year. I currently maintain several hundred thousand Atom
feeds. That will grow to millions. Thus, I will see every one of those
"unusual cases." 
	What may be rare to the vast majority of participants in this
conversation, who only maintain one or a handful of feeds, will not be
"unusual" to me...
	Can you tell me, in those "unusual cases" when there is "difficulty
in determining which instance came last," what the heck am I supposed to do
if the users expect to always see the "most recent" instance?

		bob wyman

---

From: Graham <[email-masked]>
Date: Sun, 22 May 2005 12:16:16 +0100

> What document is impossible to express with the current syntax?

At this point, it's impossible to express anything, since several of  
us are no longer sure what the meanings of atom:author and  
atom:contributor are meant to be.

(And no, Robert, it doesn't matter that you apparently are sure)

Graham

---

From: Robert Sayre <[email-masked]>
Date: Sun, 22 May 2005 08:09:37 -0400

> atom:contributor are meant to be.

No longer sure? I suggest you never will be, since the meanings of the
elements are right there in the draft, as is the cardinality. It seems
reasonable to conclude you people can't read.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Sun, 22 May 2005 13:22:30 +0100

> reasonable to conclude you people can't read.

No, we just read it a different way to what you do, the obvious way.  
The idea that atom:autho and atom:contributor are independent is just  
about a valid reading but completely counter-intuitive. There is a  
problem here.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Sun, 22 May 2005 22:23:55 +1000

> reasonable to conclude you people can't read.

Robert, humour us, please express the following use case in format-08
syntax...

    Publish an entry which indicates multiple people who are to be
    known as an "author" of the entry, and distinguish them from
    some number of persons who are to be known as a "contributor"
    to the entry (while not actually being "authors"). Their
    "contributions" might be background research, for example.
    Refer to sections 4.2.1 and 4.2.3 for the meanings of "author"
    and "contributor".

e.

---

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

> about a valid reading but completely counter-intuitive. There is a

Yes, the problem is that you think you are going to 'get it right' if
you continue to work on it. I favor the path suggested by Antone in
his excellent thread 'I wanna go home'.[0] I don't agree with all of
the resolutions, but they're not so bad, and they could be
accomplished quickly. Absurd rehashing of dates and id arguments are
not going to be resolved this year.

Robert Sayre

[0] http://www.imc.org/atom-syntax/mail-archive/msg15526.html

---

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

On 5/22/05, Robert Sayre <[email-masked]> wrote:
> It seems reasonable to conclude you people can't read.

This statement was completely inappropriate. Everyone will miss
requirements when they read a draft. The fact that everyone missed
this requirement, no matter how obvious it is under scrutiny,
indicates that this editor erred in some way. I'm not sure how it
could have been clearer without the benefit of hindsight, but that
doesn't justify the quoted sentence above. I apologize.

Robert Sayre

---

From: "Roger B." <[email-masked]>
Date: Mon, 23 May 2005 00:30:09 -0500

> if the users expect to always see the "most recent" instance?

Bob: The same thing you'd do if you had two entries with matching ids
and modified dates.

--
Roger Benningfield

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 24 May 2005 14:35:56 +0200

On Sat, 21 May 2005 17:16:25 +0200, Eric Scheid  
<[email-masked]> wrote:

> what if <author> in that example was renamed to <byline> (and specced to  
> be something other than a Person Construct), and some mechanism  
> introduced
> to indicate the nature of the contribution by each of the <contributor>s?

+1. This makes very much sense to me from a publishing company point of  
view.

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