--On Wednesday, February 02, 2005 10:12:04 AM -0800 Tim Bray <[EMAIL PROTECTED]> wrote:
On Feb 2, 2005, at 9:44 AM, Walter Underwood wrote:
On the other hand, the original plan was to publish both specs at 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.
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
