Subject: PaceEntriesElement

From: Robert Sayre <[email-masked]>
Date: Wed, 02 Feb 2005 19:13:30 -0500

http://www.intertwingly.net/wiki/pie/PaceEntriesElement

Abstract
-------------------------
Remove atom:head, group entries with atom:entries instead. Allow feeds 
to contain atom:summary and atom:content (Folders are Resources Too!).

Use cases: http://www.imc.org/atom-syntax/mail-archive/msg12963.html

Status
-------------------------
Open

Rationale
-------------------------
Making a feed document strictly hierarchical and recursive solves a 
number of problems that have been previously attacked in a piecemeal 
fashion:

  1. XML containment relates feed and entry metadata to the data being 
described, thereby defining a consistent model for future extension 
elements;

  2. Multiple feeds can be aggregated and presented using a single data 
format without having to modify the entries within those feeds to 
incorporate their original feed metadata;

  3. Digital signatures can be safely applied to feeds and entries 
without needing special-case exceptions on how to recreate the signature 
after aggregation;

  4. Simplifies description of the Atom syndication format to containers 
(feed, entries, entry, content) and metadata that targets its own parent 
(feed or entry).

  5. Allows Hierarchical feeds, comments.

  6. Practically zero changes for format05 feeds in the simple case. 
Entry elements are wrapped with atom:entries instead of headers being 
wrapped with atom:head.

  7. Differentiates elements lower in a hierarchy (collection members) 
from metadata.

---

From: "Jeremy Gray" <[email-masked]>
Date: Wed, 2 Feb 2005 19:01:22 -0800

A few quick comments before I transition out of the office and head towards
home:

In principle I am +1 for pretty much any spec that has the potential of
unifying entries and feeds, and feel even more strongly for those that also
unify comments and trackbacks with entries and feeds. A number of similar
paces have been presented over time, and I must admit that I have not had
the time I would like in order to review each in turn, so for the moment I'm
going to make a few specific comments on PaceEntryOrder and will then try to
find a bit of time this evening to re-review the other proposals before
commenting in much more detail.

The pace page on the wiki has a few things on which I'd like to comment,
some could be typo-type errors, some could be conceptual bits I either don't
understand or perhaps just don't agree with :). We'll see. On with the list:

- The pace mentions atom:head in its 4.1.2 text, but my impression of the
pace is that it would deprecate atom:head.
- The pace, in its text for 4.1.2, mentions how a feed can have any number
of entry elements. From the example, however, my impression of the pace
would be that the feed must have one entries element, which can then in turn
have any number of entry elements. I'll state my preference further in this
email, but would appreciate some clarification on what is being proposed by
the pace.
- The pace, in its text for 4.1.2, states atom:contributor cardinality rules
in the "MUST NOT" style text that conflict with the schema-style text

There may be others worth noting, but I'm out of time for my initial review
pass and must head out of the office. I'll try to do another scan, including
a review of the other similar paces, later tonight if I have a bit of time.
In the meantime, a few more "out there" pieces of food for thought in
descending order of priority from my perspective:

- merge <entry> and <feed> into <item>, then merge child elements
- add a linking construct that can support "item detail by reference", ala
the following pseudo-markup example:

<item>
  <items>
    <item>
      <title>...</title>
      <updated>...</updated>
      <link rel="detail" href="..." />
      ...
    <item>
      <link rel="detail" href="..." />
      ...
    <item>
      <link rel="detail" href="..." />
      ...
    ...

Whether via <link> or not, something like this would be very useful and
powerful indeed. May, as-is or with further refinement, handle Antone's
indirection desires.
- remove <entries>, hang children directly from the parent. If not, at least
rename it to match whatever "item"-related renaming might take place
- simmer
- enjoy

I'll see what I can do about setting aside some time to more clearly
document my thoughts, but figured it would at least be worthwhile providing
the above comments and food for thought. Since I've really scrambled to type
up this email and get out of the office, I've likely written some confusing
or outright erroneous text. If anyone has any questions or comments, don't
hesitate to contact me on-list or off. Even if I don't end up finding time
to help with the production of actual pace text, I'm more than happy to
discuss the involved issues.

Jeremy Gray

---

From: "Jeremy Gray" <[email-masked]>
Date: Wed, 2 Feb 2005 19:46:33 -0800

Here I go again. Replace "PaceEntryOrder" with "PaceEntriesElement". Ahh,
the joy of looking at too many emails all at once. :)

Jeremy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Jeremy Gray
Sent: Wednesday, February 02, 2005 7:01 PM
To: 'Robert Sayre'; 'Atom-Syntax'
Subject: RE: PaceEntriesElement

<item>
  <items>
    <item>
      <title>...</title>
      <updated>...</updated>

Jeremy Gray

---

From: James Snell <[email-masked]>
Date: Wed, 2 Feb 2005 21:36:15 -0800

Robert, 

I can see what you're trying to accomplish with this, but I have a
number of concerns.  First, this proposal is trying to muddle together
two distinctly different concepts:

1. A Feed is either a container of Entries or a Feed contains a
container of Entries

2. A Feed is a type of Entry

I don't think there is any value in mixing these two into a single
Pace because they each can be argued/rejected/adopted on their own
merits.  Splitting them into two separate Pace's would probably be a
better approach.

That said, please allow me to offer my opinion on both:

First, I tend to view a Feed as the container for entries as opposed
to a Feed having a container of entries as a property. The reason? I
think it makes the model cleaner and simpler, and makes the syntax a
bit more compact. Despite the rationale you give, I just don't see how
introducing an entries element significantly improves the Atom format.

On the second point, I understand why someone would want to have
hierarchical feeds, I just don't agree that it needs to be something
built into the Atom core.  If we can agree that a Feed is a collection
of Entries, an extension can be written that defines a Feed as a type
of Entry.  Doing so keeps the core syntax simple, while still allowing
for the cases you are trying to enable.  Further, I am not convinced
that hierarchical feeds are going to be anything more than a
limited-use edge case.

Thoughts?

-- 
- James Snell
  http://www.snellspace.com
  [email-masked]

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 03 Feb 2005 09:22:04 +0000

> described, thereby defining a consistent model for future extension 

I'm dubious about this claim. XML containment has even less semantic 
grist to it than UML aggregation. My sense is when we get down to it, 
we'll end up defining explicitly what containment means and there will 
be multiple meanings.

> incorporate their original feed metadata;

That sounds like a win.

> without needing special-case exceptions on how to recreate the signature 

Ultimately I'll defer to an expert on this, but I'd like to see an 
example of a special case that is circumvented ;)

> Entry elements are wrapped with atom:entries instead of headers being 

Why not make make atom:head an atom:entry?

>  7. Differentiates elements lower in a hierarchy (collection members) 

See my comment on 1. I think it only differentiates when we say it does, 
and this already suggests two containment 'semantics' (ie, there'll be 
an if/else in the code). Btw, this sounds like it's going to work like 
RDF/XML striping.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Thu, 03 Feb 2005 12:55:42 -0500

Bill de hÓra wrote:

>> without needing special-case exceptions on how to recreate the 
>> signature after aggregation;
> 
> 

I'm not an expert, but I have produced signed feeds. It's easy to write 
what's known as a "collectable" signature, which allows its parent 
element to appear anywhere in the document.

> Why not make make atom:head an atom:entry?

It does. It still groups the "headers". It's just implicit.

> an if/else in the code). Btw, this sounds like it's going to work like 

Yes, I wrote the initial feed in the RDF validator.

Robert Sayre