Subject: PaceEntryOrder

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 Feb 2005 10:00:55 -0800

+1. It is a simple clarification that shows the intention without 
restricting anyone.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Robert Sayre <[email-masked]>
Date: Mon, 07 Feb 2005 13:06:49 -0500

> +1. It is a simple clarification that shows the intention without 

+1. Agree in full.

Robert Sayre

---

From: Walter Underwood <[email-masked]>
Date: Mon, 07 Feb 2005 11:07:54 -0800

>> +1. It is a simple clarification that shows the intention without 

-1. I don't see the benefit. Clients MAY re-order them, but that
doesn't mean they MUST ignore the order. The publisher may prefer
an order which cannot be expressed in the attributes. The Macintouch
and BBC New feeds cited before are good examples.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Sam Ruby <[email-masked]>
Date: Mon, 07 Feb 2005 14:23:15 -0500

> and BBC New feeds cited before are good examples.

I'm +1 on the Pace as written.  I'd be equally +1 on a modifed Pace 
where "SHOULD NOT" was used in place of "MUST NOT".

- Sam Ruby

---

From: [email-masked] (John Panzer)
Date: Mon, 07 Feb 2005 10:19:25 -0800

+1.  Low cost, good benefits for interoperability.

---

From: Graham <[email-masked]>
Date: Mon, 7 Feb 2005 19:58:21 +0000

+1, with the proviso that I think the first sentence is entirely 
meaningless.

Graham

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 Feb 2005 12:24:15 -0800

>and BBC New feeds cited before are good examples.

I'm very confused. Clients that show the entries of those feeds in 
the received order are perfectly acceptable according to the wording 
of this Pace.

--Paul Hoffman, Director

---

From: David Powell <[email-masked]>
Date: Mon, 7 Feb 2005 21:14:28 +0000

> where "SHOULD NOT" was used in place of "MUST NOT".

Sam, have you misread the Pace?  The only occurrence of "MUST NOT" is
in the Rationale, where it has been copied from Atom 0.3 as an
example.

The proposal is to add the following paragraph:

   This specification assigns no significance to the order of
   atom:entry elements within the feed. Processors MAY present entries
   in a different order to which they are appear in an Atom Feed
   Document.

Also, Walter's comment seems to suggest the same confusion:

> doesn't mean they MUST ignore the order. The publisher may prefer an
> order which cannot be expressed in the attributes. The Macintouch

I'll try to be a bit more conservative with the PRE tags in future :)

-- 
Dave

---

From: Sam Ruby <[email-masked]>
Date: Mon, 07 Feb 2005 16:27:12 -0500

> I'll try to be a bit more conservative with the PRE tags in future :)

Yes, I misread it.  To be clear:

1) I am +1 to the original wording that somehow got "lost".
2) I am +1 to the proposed rewording.

Ultimately, the sentiment that I want conveyed is that publishers are 
not safe to assume that clients will read anything into the order.

- Sam Ruby

---

From: Walter Underwood <[email-masked]>
Date: Mon, 07 Feb 2005 13:44:07 -0800

--On Monday, February 07, 2005 12:24:15 PM -0800 Paul Hoffman <[email-masked]> wrote:
> the received order are perfectly acceptable according to the wording of this Pace.

Correct, clients may choose any order, including the original.

This is about the publisher's order preference. The Pace says that
the publisher cannot indicate a preferred order in the Atom format.
The order is not significant.

This is clearly counter to normal use, where the order does have
some meaning. The meaning varies by publisher, but it is usually
significant.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Walter Underwood <[email-masked]>
Date: Mon, 07 Feb 2005 13:56:17 -0800

--On February 7, 2005 4:27:12 PM -0500 Sam Ruby <[email-masked]> wrote:
>
> Ultimately, the sentiment that I want conveyed is that publishers are not
> safe to assume that clients will read anything into the order.

And I think that the order should mean "the publisher put them in this order."
The Pace forbids that interpretation.

Clients can reorder things, show only a few, whatever. I'm not restricting
client behavior.

Do other specs in the RSS family say anything about order? If order is
significant in those, then making it not significant in Atom will hurt
interoperability.

Hmm, I can't finding any ordering restrictions in a quick read of RSS 0.91 
and 2.0, but RSS 1.0 does specify ordering.

>From RSS 1.0: 5.3.5 <items>

   An RDF Seq (sequence) is used to contain all the items rather than an
   RDF Bag to denote item order for rendering and reconstruction.

   <http://web.resource.org/rss/1.0/spec#s5.3.5>

wunder