Subject: Trial format-05 atom feed

From: Tim Bray <[email-masked]>
Date: Tue, 01 Feb 2005 18:11:13 -0800

Just to see if it uncovered any problems, I twiddled the ongoing 
software to generate a format-05 atom feed.  It didn't uncover any 
problems that I could see.  Norm's RNC schema was very valuable in 
debugging, not that there were many bugs.  Check it out at 
http://www.tbray.org/ongoing/ongoing.atom

I guess the only thing that's mildly interesting is that some entries 
have <summary> and others have <content> depending on whether the whole 
thing's there.  -Tim

PS: if you open that URL in FireFox (on OS X anyhow), and FireFox asks 
you what program you'd like to open it in, do not (repeat NOT) tell 
FireFox to open it in FireFox.  Trust me on this.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Feb 2005 13:26:04 +0100

> http://www.tbray.org/ongoing/ongoing.atom

Same here (<http://greenbytes.de/tech/webdav/webdav.atom>).

Maybe it would make sense to collect URLs of test feeds on a Wiki page?

> ... 

Best regards, Julian

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

---

From: Sam Ruby <[email-masked]>
Date: Wed, 02 Feb 2005 07:29:39 -0500

> http://www.tbray.org/ongoing/ongoing.atom

the xmlns and version indicate format-04.

> have <summary> and others have <content> depending on whether the whole 

Just curious, why is the <title> on the same line as <entry>?

A blank line before every entry might also improve readability.

> FireFox to open it in FireFox.  Trust me on this.

Suggestion: try

   view-source:http://www.tbray.org/ongoing/ongoing.atom

No, it is not a registered uri scheme, but it seems to be a defacto 
standard.

- Sam Ruby

P.S.  w.r.t. the version attribute, I still believe that YAGNI.  But if 
it is to remain, I hope that the final version is mercifully short.

---

From: Eric Scheid <[email-masked]>
Date: Thu, 03 Feb 2005 00:32:48 +1100

> the xmlns and version indicate format-04.

-05 is functionally equivalent to -04 (sans errors)

e.

---

From: Sam Ruby <[email-masked]>
Date: Wed, 02 Feb 2005 09:50:42 -0500

> Same here (<http://greenbytes.de/tech/webdav/webdav.atom>).

I find your use of opaquelocktokens intriguing.  My reading of the spec 
is that opaquelocktokens are sequences of 8, 4, 4, 12 hex digits, 
separated by dashes, optionally followed by a path.

In place of a path, I see what appears to be a timestamp.  Can somebody 
cite a reference which permits such uris?

- Sam Ruby

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Feb 2005 16:13:56 +0100

> cite a reference which permits such uris?

The timestamps I am using are legal path components, according to 
RFC2068, section 3.2.1 (which RCF2518's definition for the 
"opaquelocktoken" scheme refers to). Or am I missing something?

Best regards, Julian

---

From: Tim Bray <[email-masked]>
Date: Wed, 02 Feb 2005 07:27:41 -0800

On Feb 2, 2005, at 4:29 AM, Sam Ruby wrote:

>> Norm's RNC schema was very valuable in debugging, not that there were 
>> many bugs.  Check it out at http://www.tbray.org/ongoing/ongoing.atom
>

I didn't want to fiddle with Norm's RNC.

> P.S.  w.r.t. the version attribute, I still believe that YAGNI.  But 
> if it is to remain, I hope that the final version is mercifully short.

I would be +1 on removing the version attribute.  Someone do a one-line 
Pace? -Tim

---

From: Tim Bray <[email-masked]>
Date: Wed, 02 Feb 2005 07:32:35 -0800

> Same here (<http://greenbytes.de/tech/webdav/webdav.atom>).

The empty summaries seem to me to be legal but surprising.

Hmm... the "summary" text is in the titles.  Kind of surprising but I 
guess it works.  You could just have easily have had empty titles and 
the text in the summary. -Tim

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Feb 2005 16:45:55 +0100

> the text in the summary. -Tim

Good catch -- that was a bug in my conversion code. Fixed.

Best regards, Julian

---

From: Sam Ruby <[email-masked]>
Date: Wed, 02 Feb 2005 11:22:22 -0500

> I would be +1 on removing the version attribute.  Someone do a one-line 

Done: http://www.intertwingly.net/wiki/pie/PaceRemoveVersionAttr

Note: I added some questions at the bottom.  Much to my surprise, 
scanning the current document, I don't see any "must ignore" text.

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Wed, 02 Feb 2005 08:48:29 -0800

On Feb 2, 2005, at 8:22 AM, Sam Ruby wrote:

>  Much to my surprise, scanning the current document, I don't see any 
> "must ignore" text.

Hey, we just accepted PaceExtendingAtom 24 hours or so back, give Rob & 
Mark a chance :)

---

From: Anne van Kesteren <[email-masked]>
Date: Wed, 02 Feb 2005 17:51:14 +0100

> scanning the current document, I don't see any "must ignore" text.

I really like the ideas about specifying how Atom should be both forward 
and backwards compatible and that if a new specification can not comply 
to that, a new namespace should be used.

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

---

From: Norman Walsh <[email-masked]>
Date: Thu, 03 Feb 2005 16:07:33 -0500

/ Tim Bray <[email-masked]> was heard to say:
| On Feb 2, 2005, at 4:29 AM, Sam Ruby wrote:
|
|>> Norm's RNC schema was very valuable in debugging, not that there
|>> were many bugs.  Check it out at
|>> http://www.tbray.org/ongoing/ongoing.atom
|>
|> the xmlns and version indicate format-04.
|
| I didn't want to fiddle with Norm's RNC.

I've just this minute decided that instead of trying to comment on
the -05 draft, about which I have seen a huge number of comments,
I'll go off and work on the RNG, starting with the test collection
Sam pointed me to last time I asked.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | In the life of saints, technically so
http://nwalsh.com/            | called, the spiritual facilities are
                              | strong, but what gives the impression
                              | of extravagance proves usually on
                              | examination to be a relative deficiency
                              | of intellect.--William James