Subject: New AtomPubIssuesList for 2004/12/11

From: Sam Ruby <[email-masked]>
Date: Tue, 11 Jan 2005 09:40:47 -0500

The biggest open issue (at least on the format side, and potentially on 
the protocol side) is extensibility.  I would like to see us get 
*something* into the drafts; even if imperfect, it can be incrementally 
improved upon.

So, I'm scheduling all the open extensibility and versioning paces for 
dicussion:

PaceAltExtensibilityAndVersioning
PaceExtendingAtom
PaceExtensibilityAndVersioning
PaceExtensibilityAndVersioningNoScenarios
PaceExtensionNamespace
PaceMinimalEntryVersioning
PaceMustUnderstandElement
PacePropertyDesign
PaceSupersede

- Sam Ruby

---

From: Sam Ruby <[email-masked]>
Date: Tue, 11 Jan 2005 16:28:11 -0500

[Reissuing with a corrected subject line]

---

From: Sam Ruby <[email-masked]>
Date: Thu, 13 Jan 2005 15:23:24 -0500

Based on input received, I've moved PacePropertyDesign to the 
Recommended for Closure category, and added PaceExtensionConstruct to 
the Currently Under Discussion category.

- Sam Ruby

---

From: Sam Ruby <[email-masked]>
Date: Mon, 24 Jan 2005 18:18:55 -0500

In consultation with the co-chairs (and Paul, I believe, will provide 
more details on where we go from here), I'm scheduling all the remaining 
format Paces.  If successful, this document can move forward.  If not, 
we will have a very good idea of what work is remaining, and hopefully 
can close that gap quickly.

I'm recommending AtomAsRDF and PaceFeedRecursive for closure merely 
because they are incomplete.  If they become complete, I will update 
their status accordingly.  Note: I already have scheduled 
PaceAttributesNamespace which is a progeny of AtomAsRDF.

For the remainder, there are two new Paces, PaceFeedLink, and 
PaceSimpleLanguageTagging.  The remainder are ones that we have 
discussed before without resolution.

- Sam Ruby

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 24 Jan 2005 17:03:14 -0800

> PaceAttributesNamespace which is a progeny of AtomAsRDF.

Why don't you just invent a status of "incomplete" and leave
them off the table until completed?  It doesn't make sense to
close issues that are not resolved one way or another.

I agree that they should not be considered until complete
(meaning that they contain actual draft changes).

....Roy

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 24 Jan 2005 17:52:56 -0800

>close issues that are not resolved one way or another.

It does make sense this late in the process. As we said on the list, 
after this set of Paces is evaluated, we believe we're ready to go to 
IETF last call. We have to finish sometime, and on our milestone is a 
reasonable target.

>(meaning that they contain actual draft changes).

So, if you complete the Pace fairly quickly, it can be considered in 
this last round. If you don't, it would (should!) be dropped.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 24 Jan 2005 18:11:36 -0800

> IETF last call. We have to finish sometime, and on our milestone is a 

Paul, you completely missed my point.  The Pace isn't even open yet.
It is incomplete.  It is irrelevant.  It is not closed.  Marking it
as closed takes it out of the incomplete pile and into the "finished"
pile, which is just plain weird and unnecessary.  You don't have to
address incomplete suggestions -- just ignore them.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Jan 2005 09:12:06 +0100

> IETF last call. We have to finish sometime, and on our milestone is a 

Aren't you planning to do a working-group last call before that?

 > ...

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Jan 2005 08:57:32 -0800

>Aren't you planning to do a working-group last call before that?

We're planning to ask for editorial changes after the next draft. 
Those are also welcome now on the current draft.

--Paul Hoffman, Director

---

From: Robert Sayre <[email-masked]>
Date: Sat, 29 Jan 2005 16:59:14 -0500

Sam Ruby wrote:

>  their status accordingly.

Please do.

Roy T. Fielding wrote:

>  Unfortunately, I have a paper deadline on Tuesday and can't
>  procrastinate any longer, so someone else can finish the details

I didn't include the content by reference for atom:feed and atom:entry 
that was batted around on the list, but I wouldn't oppose it. Right now, 
it's just a refactoring of atom:head.

I included versions of PaceExtensionConstruct and PaceExtendingAtom 
(mI), so the authors of those Paces should take a look.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Sun, 30 Jan 2005 09:46:03 -0500

Robert, can you take a stab at updating section 1.2 for this Pace?

I'll also note that this example is not valid.  It does not contain 
either a summary or content element.

One thing to consider is to do like what was done in Atom 0.3 [1]: 
provide both a minimal and maximal example.

- Sam Ruby

[1] http://diveintomark.org/archives/2003/12/13/atom03

---

From: Robert Sayre <[email-masked]>
Date: Sun, 30 Jan 2005 13:17:11 -0500

> Robert, can you take a stab at updating section 1.2 for this Pace?

Yes, but the Pace is complete without it.

> either a summary or content element.

Hmm. How do I do a linkblog with this restriction?

Robert Sayre

---

From: Anne van Kesteren <[email-masked]>
Date: Sun, 30 Jan 2005 19:36:23 +0100

> Hmm. How do I do a linkblog with this restriction?

I believe a linkblog should always have atom:content which provides some
information on the reason why you posted the link or a comment on the
link or something similar.

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

---

From: Sam Ruby <[email-masked]>
Date: Sun, 30 Jan 2005 14:08:14 -0500

> Yes, but the Pace is complete without it.

It would be much easier to discuss the pace with an example.

I gather that a format-05 compatible feed, thus:

   <feed>
      <entry>
         <head>...</head>
      </entry>
   </feed>

would become something like:

   <feed>
      <feed>
        <entry>...</entry>
      </feed>
   </feed>

I suspect that once people see some examples, objections will surface.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Sun, 30 Jan 2005 14:33:39 -0500

> I suspect that once people see some examples, objections will surface.

It's inappropriate for this Pace to be recommended for closure. I will 
get to the examples when I can.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Sun, 30 Jan 2005 19:06:35 -0500

> I suspect that once people see some examples, objections will surface.

I've included an example of each approach, so people can compare the two 
methods. I have not positioned them as spec text. The spec requires more 
examples no matter which approach the WG chooses.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Sun, 30 Jan 2005 19:20:51 -0500

> examples no matter which approach the WG chooses.

Good example.

- Sam Ruby