Subject: Format spec vs Protocol spec

From: Julian Reschke <[email-masked]>
Date: Tue, 01 Feb 2005 22:05:17 +0100

Hi,

(I raised this when reviewing draft 05 already, but I think this topic 
deserves it's own thread)

Currently, the format spec has a normative reference to the protocol 
spec (and also defines elements for the service URIs, for instance, 
atom:introspection).

As far as I understand the IETF publication process, this means that 
draft-ietf-atompub-format can't be published until the protocol spec is 
ready as well.

One alternative I'd like to mention is to remove all references to the 
protocol spec from the document spec including the service URI 
definitions, and to move the latter as extension elements into the 
protocol spec. This would essentially de-couple the publication process.

Thoughts?

Best regards, Julian

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

---

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

> spec (and also defines elements for the service URIs, for instance, 

I suggest this can and should be removed. --Tim

---

From: Robert Sayre <[email-masked]>
Date: Tue, 01 Feb 2005 19:19:55 -0500

Tim Bray wrote:

> I suggest this can and should be removed.

Agree.

Robert Sayre

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Feb 2005 01:30:32 +0100

>> I suggest this can and should be removed.

For the record: I made that proposal *although* I like the protocol bit 
a lot. I just want us to be able to progress both specs independently of 
each other.

Best regards, Julian

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 Feb 2005 21:40:38 -0800

At 10:05 PM +0100 2/1/05, Julian Reschke wrote:
>draft-ietf-atompub-format can't be published until the protocol spec 
>is ready as well.

Others have said we can and should remove the dependency, which is 
fine. Wearing my nitpicky-IETF-geek hat, I would point out that specs 
with dangling dependencies can be made standards without clearing the 
dependencies; they simply can't be published as RFCs with them. There 
are dozens (possibly over a hundred) IETF standards-track documents 
that have not yet been published as RFCs for a variety of reasons, 
many of them quite lame.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Walter Underwood <[email-masked]>
Date: Wed, 02 Feb 2005 09:44:10 -0800

On the other hand, the original plan was to publish both specs at
the same time, which I still think is a good idea.

Do we think there will be any dependencies in the other direction?
That is, when we work on the protocol, will we need to add things
to feed or entry? If there is a reasonable chance of that, then
Atom 1.0 is a temporary thing, and Atom 1.1 will be the real one.

If that is the case, we should leave in the dependency and
publish them together.

wunder

--On Tuesday, February 01, 2005 09:40:38 PM -0800 Paul Hoffman <[email-masked]> wrote:

> Others have said we can and should remove the dependency, which is fine. Wearing my nitpicky-IETF-geek hat, I would point out that specs with dangling dependencies can be made standards without clearing the dependencies; they simply can't be published as RFCs with them. There are dozens (possibly over a hundred) IETF standards-track documents that have not yet been published as RFCs for a variety of reasons, many of them quite lame.
>
> --Paul Hoffman, Director

--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Tim Bray <[email-masked]>
Date: Wed, 02 Feb 2005 10:12:04 -0800

> the same time, which I still think is a good idea.

I don't.  I think that if the format depends on the protocol, that's a 
*bug*, because I'm quite sure that a nice minimal clean general-purpose 
vocabulary like Atom will find a wide range of applications in areas 
that we haven't begun to think of, that couldn't care less about 
publishing protocols.  So it would be actively harmful if the format 
had a dependency on the protocol.

The reverse is not true, it's OK for the protocol to depend on the 
format.

Finally, I think the group needs to get the format signed, sealed and 
delivered so that we can focus our energies on getting the protocol 
right.  -Tim

---

From: Walter Underwood <[email-masked]>
Date: Wed, 02 Feb 2005 10:56:29 -0800

--On Wednesday, February 02, 2005 10:12:04 AM -0800 Tim Bray <[email-masked]> wrote:
> I don't.  I think that if the format depends on the protocol, that's a *bug*,
> because I'm quite sure that a nice minimal clean general-purpose vocabulary
> like Atom will find a wide range of applications in areas that we haven't
> begun to think of, that couldn't care less about publishing protocols. So it
> would be actively harmful if the format had a dependency on the protocol.

Hmm, I wasn't clear. While we are working on the protocol, will we
learn things that need to be applied to the format? The protocol is
an application of Atom. There will be lots of others, but this one is
core, by definition. Previous feed formats have not had an editing aspect,
so it wouldn't be a complete surprise to find something missing in Atom.

We are assuming that Atom will need extensions for new applications,
but it should not need extensions for editing blog entries.

Mutual dependencies are normal. HTTP and XML have that for encodings.
XML talks about encoding specs from transports and HTTP content-type
overrides format encodings in the entity.

Some areas that might come up are clocks and dates (date from client
or server?), security, and editing-only extensions (not copied to feed).
An example of the last on is marking an entry as draft or published.
That information would not show up in a regular feed, but would be
there in a feed used for archiving.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Antone Roundy <[email-masked]>
Date: Wed, 2 Feb 2005 11:53:29 -0700

> but it should not need extensions for editing blog entries.
I'd have to disagree.  I don't think it inappropriate for elements that 
exist for use by the publishing protocol to live in a separate 
namespace from the feed itself.  Rather, I think that a clean 
separation between the two would be desirable.  Why require the feed 
format to be revised if we really just want to alter the publishing 
protocol?

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 2 Feb 2005 14:06:29 -0500

> protocol spec. This would essentially de-couple the publication process.

+1

-- 
Joe Gregorio        http://bitworking.org

---

From: Robert Sayre <[email-masked]>
Date: Wed, 02 Feb 2005 14:11:46 -0500

> so it wouldn't be a complete surprise to find something missing in Atom.

One of the demonstrated problems in syndication[0] and editing APIs is 
representation of collections with collections.

-------------------------------
Disclaimer: The following paragraph is not an edorsement of WebDAV's 
requirements, syntax, or extension of HTTP.
-------------------------------

One thing WebDAV does get right to some extent is representation of 
sub-collections. This approach is provably effective. Some example 
applications based on this approach:

* Outlook Web Access is based entirely on XSL-transformed DAV XML, and 
Javascript's XMLHttpRequest.

* Outlook Express's Hotmail accounts use this protocol as well.

The problems facing a server storing blog entries are not much different 
(whether or not the entries are exposed to APP). The implementation 
requirements of those protocols far excede anything we can expect, but 
some aspects of the model would be extremely valuable to the format and 
protocol, IMHO.

Robert Sayre

[0] 
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=a257ba40-b9fd-4cba-959a-2bba6ae917f0

---

From: Walter Underwood <[email-masked]>
Date: Wed, 02 Feb 2005 11:33:23 -0800

--On Wednesday, February 02, 2005 11:53:29 AM -0700 Antone Roundy <[email-masked]> wrote:
> I'd have to disagree.  I don't think it inappropriate for elements that exist for use by the publishing protocol to live in a separate namespace from the feed itself.  Rather, I think that a clean separation between the two would be desirable.  Why require the feed format to be revised if we really just want to alter the publishing protocol?

I'm not talking about altering the publishing protcol, I'm talking about things
needed to make 1.0 work. It would seem a little odd if we needed extensions
or a 1.1 for the 1.0 publishing protocol.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Antone Roundy <[email-masked]>
Date: Wed, 2 Feb 2005 12:35:31 -0700

On Wednesday, February 2, 2005, at 12:33  PM, Walter Underwood wrote:
>> I'd have to disagree.  I don't think it inappropriate for elements 
>> that exist for use by the publishing protocol to live in a separate 
> I'm not talking about altering the publishing protcol,
Right, I was just saying that if, someday, after format 1.0 and 
protocol 1.0 are out, we discover the need to alter the protocol, have 
the two separated from either other would enable us to do that without 
affecting applications that use the format but not the protocol.

> I'm talking about things
Let me make sure I understand you correctly--are you saying that it's 
fine for the format and protocol to have their own elements in their 
own namespaces, but 1.0 of each should be finished at the same time, to 
ensure that we don't run into any surprises while finishing protocol 
1.0 which require a format revision (eg. 1.1) in order to make protocol 
1.0 work?  Or are you saying that everything needed for editing should 
be in the format namespace, not an extension?  I suppose I can't 
comment on the former, because I haven't been involved in the protocol 
discussion, but I definitely wouldn't agree with the latter.

---

From: Walter Underwood <[email-masked]>
Date: Wed, 02 Feb 2005 12:06:58 -0800

Correct. --wunder

--On February 2, 2005 12:35:31 PM -0700 Antone Roundy <[email-masked]> wrote:

> Let me make sure I understand you correctly--are you saying that it's fine for the format and protocol to have their own elements in their own namespaces, but 1.0 of each should be finished at the same time, to ensure that we don't run into any surprises while finishing protocol 1.0 which require a format revision (eg. 1.1) in order to make protocol 1.0 work? 

--
Walter Underwood
Principal Architect, Verity

---

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

Robert Sayre wrote:
> (whether or not the entries are exposed to APP).

Our secretary has listed the following paces as "organization" paces, 
meaning they don't change the definition of many core elements other 
than the ones serving as "containers".

* PaceAggregationDocument
* PaceFeedRecursive

1.) A web forum, where one post serves as the root of a collection of
     other posts.

     HTML--
     http://groups-beta.google.com/group/bloggerDev/

     Atom 0.3, "root" posts only--
     http://groups-beta.google.com/group/bloggerDev/feed/topics.xml

     Atom 0.3, all messages--
     http://groups-beta.google.com/group/bloggerDev/feed/msgs.xml

2.) A Blog w/ comments, where on post serves as the root of a collection
     of other posts.

     HTML--
     http://www.livejournal.com/users/giant_moose/

     Atom 0.3, no indication of comments--
     http://www.livejournal.com/users/giant_moose/data/atom

3.) A "List Status" feed, where the only updates consist of one
     collection replacing another.

     RSS2 --
     http://rss.netflix.com/Top100RSS

     background info--

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Thu, 03 Feb 2005 18:15:48 -0800

>     http://groups-beta.google.com/group/bloggerDev/feed/msgs.xml

Q: Has any previous flavor of RSS had a solution for this?

Potential solutions that occur to me:

1. Ignore the problem
2. PaceEntriesElement could handle this
3. PaceFeedRecursive could handle this
4. PaceAtomHeadInEntry could handle this
5. PaceAggregationDocument could handle this

I honestly can't say which I prefer.  Would anyone like to try to put  
together examples of the solution in #2 through #5 so that we can  
consider the alternatives?

>     http://www.livejournal.com/users/giant_moose/data/atom

Q: Has any previous flavor of RSS had a solution for this?
Q: Do we have a proposal on something to handle this?

I believe there is a proposal for a <link rel="comment"> which would do  
the job.

> http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=a257ba40-b9fd 

Q: Has any previous flavor of RSS had a solution for this?
Q: Do we have a proposal for something to handle this?

Dare points out that the feed suffers from lack of guids and dates,  
something that Atom would force them to fix, which would give an  
aggregator a better chance of doing something useful.  -Tim

---

From: Robert Sayre <[email-masked]>
Date: Thu, 03 Feb 2005 21:54:31 -0500

> Q: Has any previous flavor of RSS had a solution for this?

By reference, there is wfw:commentrss. That's typing of items/entries by 
the type of link relation that points to them. That means you're going 
to have people calling things "comments" to get the interface to happen. 
It's nesting.

> consider the alternatives?

I will put together examples for all of the alternatives, and I will add 
  one more example: planetsun.org.

> Q: Has any previous flavor of RSS had a solution for this?

No, but the problem isn't that hard. I wouldn't be surprised if LJ has 
some private format for this, but I don't know if they do.

> Q: Do we have a proposal on something to handle this?

PaceEntriesElement would do it.

> I believe there is a proposal for a <link rel="comment"> which would do  

It wouldn't handle that example. The comments are nested. XML elements 
nest pretty well. It would handle the first case... but only by 
reference. You couldn't "subscribe to posts with comments".

> Q: Has any previous flavor of RSS had a solution for this?

Yes. http://npg.nature.com/pdf/newsfeeds.rdf, or there is OPML.

> Q: Do we have a proposal for something to handle this?

Yes, any of the "organization" Paces would take care of this, other than 
the ordering problem, which no Pace addresses.

> aggregator a better chance of doing something useful.  -Tim

Nesting collections would make the situation explicit.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Fri, 04 Feb 2005 14:13:32 +1100

> reference. You couldn't "subscribe to posts with comments".

I know of at least one blog where the comments are neither hierarchical nor
flat ... each comment can be in reply to multiple previous comments. How
would you model this in XML?

I would use

    <link rel="in-reply-to" .../>
    <link rel="in-reply-to" .../>
    <link rel="in-reply-to" .../>

and 

    <link rel="has-reply" .../>

(guessing at the @rel values)

e.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 04 Feb 2005 14:26:12 +1100

> aggregator a better chance of doing something useful.  -Tim

This is not too much unlike how Nature Publishing Group is providing RSS1.0
feeds of table of contents for each issue of their journals. They have one
feed URI for each issue, and a 304 redirect on the "current issue" feed URI.
Each article has a unique id. They also have an RSS feed where each item is
a link to each of their various journal titles. They could also quite
reasonably have a per-title feed where each item is a link to each issue's
feed.

e.

---

From: Antone Roundy <[email-masked]>
Date: Thu, 3 Feb 2005 21:58:25 -0700

On Thursday, February 3, 2005, at 07:54  PM, Robert Sayre wrote:
>> I believe there is a proposal for a <link rel="comment"> which would 
>> do  the job.
>
I don't see any reason why a feed reader couldn't give you the option 
of automatically subscribing to the comment feeds that grow off of the 
posts in a feed and automatically organize those subscriptions 
hierarchically under the original.  Then, if a thread got 
uninteresting, you could unsubscribe to just that part of it and never 
have to download that chunk of it again.  A slight variation would be 
to provide a one-click subscription to comments off of the top level, 
and then automatically subscribe to the threads underneath it--that 
would require a lot less manual maintenance to avoid overload.  If the 
top level were fully automatic, it would be pretty messy for a high 
volume site like Slashdot, for example, but a nested comments feed 
would be worse, since it would be less simple to hack off the 
uninteresting threads.

---

From: James Snell <[email-masked]>
Date: Thu, 3 Feb 2005 21:42:07 -0800

> consider the alternatives?

6. Handle the problem in a non-core extension.  

The core Atom syntax does not have to deal with all these cases as
long as it does not interfere with someones ability to deal with cases
later on. Get version one out the door.  Get folks to start
implementing it.  Start writing up extensions.  Get folks to implement
those extensions.  Figure out which extensions are Really Useful.  Add
those Really Useful Extensions to the core later.

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

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 04 Feb 2005 10:02:29 +0000

> 6. Handle the problem in a non-core extension.  

I'm inclined to keep our options open on these use-cases being in or out 
of core. We don't have an extension mechanism yet other than 
atom:link[@rel]. Certainly Atom format work to date hasn't been framed 
as getting the evaluation of extensions right. It's might be difficult 
to add meaningful stuff later when there's no design for adding 
meaningful stuff today.

cheers
Bill