Subject: The Atom Format end-game

From: Tim Bray <[email-masked]>
Date: Wed, 05 Jan 2005 17:26:02 -0800

This represents the result of discussions between Paul and myself, and 
is our position as co-chairs of the Atompub WG.

Beginning with the conclusion:

1. We *must* finalize the format.  Our deadline is drawing near and we 
need to focus on the publishing protocol.
2. We are close to RSS2 feature-compatibility, we either adopt image & 
enclosure or make a conscious decision not to.
3. Based on the detailed analysis below from the mailing list, there is 
rough consensus that the only remaining point we MUST settle in the 
format is extensibility.   Likely MustIgnore can gain consensus support 
via PaceExtendingAtom, perhaps with some fine-tuning.  Which leaves 
MustUnderstand.  It is possible that PaceMustUnderstandElement might 
get in if we either convince Joe Gregorio or decide to declare rough 
consensus over his objections. Or maybe not. Co-chairs can live with 
either.

Basis for this analysis:

Hoffman: http://www.imc.org/atom-syntax/mail-archive/msg11315.html
- What's the Minimum Progress Required to Declare Victory?

Here's what was offered in response: [CO-CHAIR COMMENTS LIKE THIS].

Sayre: http://www.imc.org/atom-syntax/mail-archive/msg11327.html
- PaceFieldingLinks [ACCEPTED]
- PaceUpdatedDefinition [ACCEPTED]
- Extensibility

Parks: http://www.imc.org/atom-syntax/mail-archive/msg11323.html
  - atom:updated is currently required. I think this will lead to it 
being polluted with general "Last Modified" dates, severely limiting 
its usefulness. Seeing as it is not possible to make an element 
optional after v1.0, but it is possible to do the reverse, this one 
seems urgent. [REQUIRES A PACE, GIVE IT A TRY, WE'RE PESSIMISTIC]
  - The discredited atom:id canonicalization nonsense still stands 
[DITTO]
  - The use of terminology is very poor. For example, several elements 
define whether they can "change" or not. How can a server ever change 
something after it has been transmitted? What we mean to say is whether 
or not all instances of an entry should have the same value. [SAYRE 
ACCEPTED THIS AS AN EDITORIAL ISSUE]
  - ditto "permanent, universally unique identifier" [DON'T UNDERSTAND]
  - No discussion on how xml:space applies to content types [DO A PACE, 
MIGHT FLY]
  - type="TEXT" does not define handling of line breaks [DITTO]
  - No discussion on whether whitespace or parameters are allowed in 
@type [DITTO]
  - Section 6 "Managing Feed State" could be a key differentiator 
between Atom and RSS if it were written rather than dropped [DO A PACE, 
BUT WE'RE PESSIMISTIC]

Roundy: http://www.imc.org/atom-syntax/mail-archive/msg11318.html
  - Links: I'd love to see this nailed down a little better, but my hope 
of reaching consensus is fading, and I don't know how much more energy 
I'll feel inclined to contribute to the effort. If we're going to punt 
on making this really good, but there are any minor tweaks that we CAN 
agree on, let's at least do those. [AGREE WITH PESSIMISM]
  - PaceHeadInEntry: Is there any reason not to put this in? (Note: I 
think it could use an example of an aggregated feed--the only example 
it has now is Atom over XMPP.) [ACCEPTED]
  - Categories: Sometimes useful. Never problematic, as far as I can 
tell. Shouldn't be too hard to nail down the specifics. Let's put it 
in. [PaceCategoryRevised ACCEPTED]
  - Enclosures/Images (both "favicons" and other feed- or entry-related 
images): Although one might use HTML in the content to point to some of 
these, for CaRP (which displays newsfeeds on webpages), I find it 
extremely useful to have these in a separate element--it gives the user 
much greater flexibility in formatting the output. Of course, if the 
publisher wants an image to be displayed in a particular way in 
relation to the rest of the content, then pointing to it from within 
the content is necessary, but if they simply want to specify an image 
(or whatever) to have displayed alongside the content in some way or 
another, a separate element is preferable. [PaceEnclosuresAndPix 
ADDRESSES THIS]
  - Explicit entry deletion: Another "why not put it in". Yes, once 
you've published something, it's out there, and you can't expunge it 
completely, but Arve's use-case[1] for deletion shows that there would 
be a real benefit to having a deletion mechanism (assuming it would get 
implemented, which I expect it would). This should be easy enough to 
hammer out specifics for[2]. Let's do it. [PROTOCOL, NOT FORMAT]
  - General Extensibility: I see no reason to rush to 1.0 without 
nailing this down better. On the other hand, I personally don't care 
much about the specifics, so I also see no reason to wrangle over them 
for a long time, if that's what would have to happen to get it done.

Morin: http://www.imc.org/atom-syntax/mail-archive/msg11302.html
- Include schemas! [WE AGREE, BUT WE THINK WE'LL GET THEM SOON AS WE 
ASK, LOTS OF PEOPLE SEEM HAPPY TO VOLUNTEER]

Gregorio: http://www.imc.org/atom-syntax/mail-archive/msg11287.html
- Any mention of extensibility in the format spec.
- A feed level 'image' element, ala RSS 2.0 which, "Specifies a GIF, 
JPEG or PNG image that can be displayed with the channel." 
[PaceEnclosuresAndPix ADDRESSES THIS]

---

From: Robert Sayre <[email-masked]>
Date: Thu, 06 Jan 2005 01:48:18 -0500

Tim Bray wrote:

> 3. Based on the detailed analysis below from the mailing list, there 
> is rough consensus that the only remaining point we MUST settle in the 
> format is extensibility.   Likely MustIgnore can gain consensus 
> support via PaceExtendingAtom, perhaps with some fine-tuning.  

Agree.

> Which leaves MustUnderstand.  It is possible that 
> PaceMustUnderstandElement might get in if we either convince Joe 
> Gregorio or decide to declare rough consensus over his objections. Or 
> maybe not. Co-chairs can live with either.

I've heard convincing use cases for mU, but nothing that suggests we're 
adding anything that a SOAP header wouldn't take care of. If someone 
needs mU, why wouldn't they just send a feed or entry in a SOAP 
envelope, and make use of all that existing mU infrastructure? Also, 
when mU headers are added in HTTP 2.0, we get them for free ;)

Put another way, seems like protocol, not format.

> something after it has been transmitted? What we mean to say is 
> whether or not all instances of an entry should have the same value. 
> [SAYRE ACCEPTED THIS AS AN EDITORIAL ISSUE]

I had forgotten about this one, but Graham is correct that the spec 
needs to be looked over for handwaving and insular atomisms.

> be a real benefit to having a deletion mechanism (assuming it would 
> get implemented, which I expect it would). This should be easy enough 
> to hammer out specifics for[2]. Let's do it. [PROTOCOL, NOT FORMAT]

The Atom-over-XMPP draft[0] and its WebDAV doppelganger[1] already 
report these events.

Maybe those specs should define syntax to report executed HTTP events 
and re-use them in all three protocols (?).

Robert Sayre

[0] http://ietfreport.isoc.org/idref/draft-saintandre-atompub-notify/
[1] http://ietfreport.isoc.org/idref/draft-hildebrand-webdav-notify/

---

From: Danny Ayers <[email-masked]>
Date: Thu, 6 Jan 2005 15:50:03 +0100

> consensus over his objections. Or maybe not. Co-chairs can live with

Agreed, apart from the latter part of 3.

Regarding extensibility, don't forget that mustUnderstand/mustIgnore
is not the only game in town. Directly related is the point that
feature-parity with RSS 1.0 should be considered as well as parity
with RSS 2.0. The issues raised in Tony Hammond's paper on science
publishing [1] have yet to be addressed.

(Note I'm not talking of replacing mustUnderstand, just that it
doesn't cover what's needed in this context).

Googling "site:www.imc.org extensibility" or better still
"site:www.imc.org extensibility rdf" seems to yield a lot of the
relevant posts on-list, e.g. [2] from Dan Brickley who has a few
samples to test the extensibility of Atom.

The potential benefits of RSS 1.0-like extensibility have often been
stated on-list. One regular counter-argument has been along the lines
of "I don't see what that buys us" (usually from Dare ;-), which has
usually prompted yet another rewording of what it does buy us.

The other common counter-arguments have been essentially "it's not
worth the model complication"/"it's not worth the syntax
complication". RDF/XML syntax was rejected before the IETF group was
even set up, all the proposals since have only involved at most minor
changes to the way the syntax is now. In terms of model, there is a
strong argument that reference to an RDF model, even if it is only
informative, can make the core Atom model clearer (was it mnot made
this point early on?). RSS 1.0 demonstrates that an XML syntax mapped
to a common model can disambiguate extensions.

But Atom extensibility doesn't necessarily have to be defined in terms
of the RDF model anyway to get these benefits (though it would IMHO be
the easiest approach). Structural rules relating a constrained XML
syntax of extensions to the Atom conceptual model (as described in the
charter) could provide virtually the same benefits. The rules could be
almost trivially simple, e.g. "child elements of an <entry> are always
properties of that entry".

As evidence why we need to consider this prior to Atom version 1.0,
I'd point to all the (occasionally heated) disagreement surrounding
extension of the <enclosure> element in RSS 2.0 (starting with the
multiple elements issue, but then more generally e.g. see [3]). Having
a common structural framework in the XML syntax would have led to
improved consistency rather than conflict due to distributed ad
hoc-ness. Even if several different vocabularies were used for the
same kinds of data, mapping between them would be considerably easier.

Whatever happens it will be possible to fire Atom XML through XSLT to
produce RDF/XML (probably largely RSS 1.0). But without a consistent
way of interpreting extensions, that data will be unavailable to RDF
tools. But this is only a secondary concern.

If structural interpretation of the syntax is consistent, then life
will be easier for all application developers and Atom can be of
maximum utility, on the peak of the effort/benefit curve.

Cheers,
Danny.

[1] http://dlib.anu.edu.au/dlib/december04/hammond/12hammond.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg08539.html
[3] http://groups.yahoo.com/group/rss-media/messages

-- 

http://dannyayers.com

---

From: Henry Story <[email-masked]>
Date: Thu, 6 Jan 2005 16:56:02 +0100

I have proposed that Atom can be considered as a form of RDF already 
[1], and have given an example of how one needs to think of it for this 
to be the case. The consequences of this would be that the atom syntax 
need not change, and that there is a clear model for extensibility of 
atom.

Of course this just shows that the working group is very close to 
having what it wants. But the details need now to be checked and 
verified officially, and presumably some language appear in the spec as 
to this being officially the correct reading.

I can just point to the glaring solution to the extensibility problem. 
I don't know what more I can do.

Henry Story

[1] http://www.imc.org/atom-syntax/mail-archive/msg11850.html

On 6 Jan 2005, at 15:50, Danny Ayers wrote:

>> is
>> support

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 06 Jan 2005 17:53:51 +0100

On Wed, 05 Jan 2005 17:26:02 -0800, Tim Bray <[email-masked]> wrote:

> It is possible that PaceMustUnderstandElement might get in if we
> either convince Joe Gregorio or decide to declare rough consensus
> over his objections.

Not sure that it matters, and I do not speak up just to obstruct  
consensus, but I am, and have always been, against a 'must understand'  
mechanism as well. I do not think it buys as much as it takes in terms of  
simple implementation and such, so I'm -1 on this.

> being polluted with general "Last Modified" dates, severely limiting its  
> usefulness.

I think so as well, but anything and everything is an improvement over  
today's situation, so I really don't care about the date discussion  
anymore. People will abuse these elements with whatever type of dates  
their publishing software provides them with, and in most cases, that's an  
ambigous date no one can say anything certain about. That's the way people  
like it, and that's fine.

>   - ditto "permanent, universally unique identifier" [DON'T UNDERSTAND]

I don't understand this comment either. What's wrong with the wording?

> [PaceCategoryRevised ACCEPTED]

+1.

> extremely useful to have these in a separate element

I agree.

> [PaceEnclosuresAndPix ADDRESSES THIS]

I just wonder; how is 'size' more interesting to consumers than 'width'  
and 'height'? I, as a consumer of RSS feeds have more often wondered about  
the resolution of the images attached to entries and such rather than  
their physical size in kilobytes. But it might only be me.

>   - Explicit entry deletion: [...] Let's do it. [PROTOCOL, NOT FORMAT]

I agree about both doing it and that it belongs in the protocol.

I also have some last comments to the latest format draft:

   3.2.2  "atom:uri" Element

I think everyone agrees that the name of this element shouldn't be 'uri'  
but something more coherent with the rest of the specification. I see no  
reason why we need a pace to express this, but if someone thinks we do,  
I'll create one. Why can't both this and the '3.2.3  "atom:email" Element'  
be Link constructs, for example?

   3.5.1  "rel" Attribute

    [...] Link constructs MAY have a rel attribute, whose value MUST
    be a string [...]

What's a «string»? Do we need a definition?

   3.6.1  Dereferencing Identity Constructs

I think this section in particular (but also a heap of others) is in  
desperately need of examples.

   4.  The "atom:feed" Element

   [...] Its first element child MUST be atom:head, which MAY be
   followed zero or more atom:entry child elements.

Isn't there a 'by' too little in there, e.g.: «... which MAY be followed  
by zero or more atom:entry child elements».

   4.2.9  "atom:generator" Element

   [...] The atom:generator element MAY have a "uri" attribute [...]

Why doesn't this element's attributes have their own sections, like all(?)  
other attributes in the specification? And what's wrong with 'href'? Why  
isn't 'atom:generator' a Link Construct?

   4.2.10  "atom:copyright" Element

   [[Is the following paragraph bogus amateur lawyering? The first
   paragraph seems sufficient.]]

I agree. The first paragraph seems sufficient.

   4.2.11  "atom:info" Element

I think this needs some explanation. Examples are nice.

   5.2  "atom:link" Element

   atom:entry elements MUST contain at least one atom:link element with
   a rel attribute value of "alternate".

Wasn't PaceContentOrLink accepted, so that 'atom:link' is only required in  
'atom:entry' if 'atom:content' is missing?

   atom:entry elements MUST NOT contain more than one atom:link element
   with a rel attribute value of "alternate" that has the same type
   attribute value.

I'd like to see it combined with 'lang' as well: «atom:entry elements MUST  
NOT contain more than one atom:link element with a rel attribute value of  
"alternate" that has the same type and lang attribute value».

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: Antone Roundy <[email-masked]>
Date: Thu, 6 Jan 2005 10:18:10 -0700

> usually prompted yet another rewording of what it does buy us.

Part of the problem is that the benefits of RDF are often explained in 
language that, while I assume it's clear to people conversant with RDF, 
is only vaguely comprehensible, and that with effort, to those of us 
who aren't.  From time to time I catch a glimpse of the value of RDF, 
but I doubt that I've ever really seen the big picture.  I see two 
pages on the wiki addressing the RDF or not question 
(http://www.intertwingly.net/wiki/pie/NoToRdf and 
http://www.intertwingly.net/wiki/pie/XmlAndRdf), but neither strikes me 
as being a good "the big picture of RDF benefits for non-RDF speakers" 
page.

Another part of the problem is that some people simply don't care about 
the benefits that RDF offers.  While I'm sure the benefits are more 
than worth cost of RDF syntax to those who do care about those 
benefits, they are not for those who don't.  Is there a way to 
reconcile the needs of the two groups?

I see four possible futures:

1) Atom does not use RDF and is not defined and constrained in a way 
that makes it easy to convert to RDF (including elements from other 
namespaces).  This would make Atom significantly less useful to those 
who care about RDF's benefits.

2) Atom does not use RDF, but it is defined and constrained in ways 
that make it easy to convert to RDF (including extensions).  This 
should be at least minimally acceptable to pretty much everyone.

3) Atom uses RDF, adding a lot of syntactic overhead and/or variability 
to its structure.  This would make Atom significantly less appealing to 
those who aren't conversant with RDF and/or using RDF-aware tools.

4) Atom uses RDF, but the way documents are structured is constrained 
to a subset of how RDF can be structured so that it doesn't require 
RDF-aware tools to process, and the amount of overhead added by the RDF 
syntax is minimal.  This should be at least minimally acceptable to 
pretty much everyone.

Which of #1 and #2 are we closest to right now?  Is #2 or #4 
achievable?  If so, which is preferable?  I'd like to aim for #2, but 
if the overhead and obfuscation in the eyes of non-RDF speakers of #4 
is truly minimal (I suspect that RDF speakers and non-RDF speakers 
would have very different definitions of "truly minimal"), I'd have no 
complaints about going that route.  Also, in either case, if working 
toward a particular solution significantly increases our time to 
completion, that's a major strike against it.

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Thu, 06 Jan 2005 18:30:39 +0100

> I agree about both doing it and that it belongs in the protocol.

Hm. I think there may be some confusion here:

-  Actually deleting an entry can be done with HTTP DELETE. Which is  
RESTFUL
-  Informing your subscribers that an entry resource has been  
retracted/deleted is an entirely different matter, and does, IMHO belong  
in format, rather than protocol.

-- 
Arve Bersvendsen

http://www.bersvendsen.com/   /   http://www.virtuelvis.com/

---

From: Henry Story <[email-masked]>
Date: Thu, 6 Jan 2005 18:43:36 +0100

To restate my point in your terms I believe I have shown that your 
point (4) is currently true. Ie (4) is not a future. It is currently 
and actually true.

Like RSS1.0 Atom is a constrained form of RDF. But unlike RSS1.0 it is 
very inconspicuously so. IE. Anyone just looking at atom would never 
guess that it is RDF.

I have tried to show this in an e-mail [1] to this list. Of course it 
would require more work to show this definitively to be the case. I 
have not gone through the details of this work because I'd like to have 
the backing of the group to do this officially, before I spend too much 
time on it. Also I would probably find a  lot of people a lot more 
knowledgeable than me to help on this task if there was a declared 
interest.

Henry Story

[1] http://www.imc.org/atom-syntax/mail-archive/msg11850.html
     I later found ways around most (all?) of the problems I had 
identified in that mail on the atom-owl mailing list.

On 6 Jan 2005, at 18:18, Antone Roundy wrote:

> 3) Atom uses RDF, adding a lot of syntactic overhead and/or 
> variability to its structure.  This would make Atom significantly less 
> appealing to those who aren't conversant with RDF and/or using 
> RDF-aware tools.
>
> RDF-aware tools to process, and the amount of overhead added by the 
> RDF syntax is minimal.  This should be at least minimally acceptable 
> to pretty much everyone.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 6 Jan 2005 10:27:00 -0800

At 6:43 PM +0100 1/6/05, Henry Story wrote:
>Like RSS1.0 Atom is a constrained form of RDF. But unlike RSS1.0 it 
>is very inconspicuously so. IE. Anyone just looking at atom would 
>never guess that it is RDF.
>
>I have tried to show this in an e-mail [1] to this list. Of course 
>it would require more work to show this definitively to be the case. 
>I have not gone through the details of this work because I'd like to 
>have the backing of the group to do this officially, before I spend 
>too much time on it. Also I would probably find a  lot of people a 
>lot more knowledgeable than me to help on this task if there was a 
>declared interest.

Wearing my co-chair hat, the reason I didn't give backing is that I 
didn't hear much desire for it. That is not to say you shouldn't do 
it, just that it was not needed to be a WG work item.

It is quite common in the IETF that there are set of WG work items 
*and* individually-submitted drafts that extend, explain, or 
otherwise refer to the WG work items. If you wanted to create a draft 
that would eventually become an Informational RFC that explained how 
the Atom format as we are discussing it relates to RDF, I'm sure that 
would be useful to some people (and possibly many more than we can 
imagine right now).

So, instead of me saying "feel free to do it", let me encourage you 
to do it. It doesn't affect the WG products or timelines, but could 
have a positive effect of eventual Atom use.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Graham <[email-masked]>
Date: Thu, 6 Jan 2005 19:48:38 +0000

> I don't understand this comment either. What's wrong with the wording?

The full phrase is:
"permanent, universally unique identifier for the construct's parent"

This could, in good faith, be interpreted to require a random number 
generator:
- Permanent: I have no way to change it after I've transmitted it
- Universally unique: Yes
- The construct's parent: I'm taking this to mean this the XML chunk 
I've just generated, and it identifies that for you just fine

It is not "universally unique", it is unique to instances of the entry 
being described. Similarly "permanent" is redundant in the same way 
that describing values as "change"-able is nonsense. Compare with what 
I wrote for PaceIDConstruct2:

         Identification Constructs convey an identifier that is used
         to associate different instances of the same resource.
         Whenever a resource appears in an Atom Document, its
         identifier SHOULD be the same as any other times it has
         appeared in an Atom Document, and MUST NOT be the same as the
         identifier currently or formerly used for any other Atom
         resource.  Changes to the content or location of the resource
         MUST NOT change the identifier. All Atom Documents published
         by the same entity MUST use the same identifier for each
         respective resource they publish.

It's still not perfect, but it actually gets across what we mean.

Graham

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 07 Jan 2005 01:56:24 +0100

> - Universally unique: Yes

A random number might be globally unique but not universally. Maybe we  
need to explain the difference? Globally unique is unique within the  
moment of time the ID is generated. Universally unique is unique at that  
time and «forever».

> I've just generated, and it identifies that for you just fine

Could you be more specific about how you interpret it? Examples would be  
nice.

> being described.

Within what context? Anyway; if it's not universally unique, it doesn't  
comply to the specification and thus is no good. The risque of two entries  
having the same ID is too high when an ID is not either of «permanent» or  
«universally unique».

> Similarly "permanent" is redundant in the same way that describing values
> as "change"-able is nonsense.

How is it redundant? People change these things all the time. What magic  
have been done that have made them stop?

>          respective resource they publish.

This only seems to suggest that two entries within the same feed shouldn't  
have the same identifier, and doesn't deal with syndication-related  
problems with identifiers at all. With your text proposal, I think it  
looks all right to have ID's match cross-feed, no matter whether they're  
the same entry or not. I don't think that's okay.

> It's still not perfect, but it actually gets across what we mean.

Maybe it gets across what you mean, but not what I do.

---

From: Graham <[email-masked]>
Date: Fri, 7 Jan 2005 01:57:16 +0000

On 7 Jan 2005, at 12:56 am, Asbjørn Ulsberg wrote:

> moment of time the ID is generated. Universally unique is unique at 
> that time and «forever».

Exactly my point, "universally unique" requires that all instances of 
atom entries to have different ids, even when they contain the same 
blog entries.

(yes, a random number generator would repeat. My bad)

> Could you be more specific about how you interpret it? Examples would 
> be nice.

A server generates XML for client A and stamps it with a number. A 
server generates new XML for client B and therefore stamps it with a 
new number to identify it (even though it contains the same atom 
entry). I'm reading parent element to be the <entry> node that I just 
created in memory. The text says nothing about the identifier belonging 
to one blog entry.

> How is it redundant? People change these things all the time. What 
> magic have been done that have made them stop?

The Atom spec describes how to assemble an XML file. How can anyone 
insert "permanent" characters into a file, write them in blood? What we 
want people to do is use the same identifier as the last time they 
assembled a file, which is a whole other thing from "permanent".

> This only seems to suggest that two entries within the same feed 
> shouldn't have the same identifier, and doesn't deal with 
> syndication-related problems with identifiers at all.

TELEGRAM FOR MR A. ULSBERG:
"Its identifier... MUST NOT be the same as the identifier currently or 
formerly used for any other Atom resource" STOP

Graham

---

From: Antone Roundy <[email-masked]>
Date: Thu, 6 Jan 2005 21:17:41 -0700

> atom entries to have different ids, even when they contain the same 
...
> created in memory. The text says nothing about the identifier 
> belonging to one blog entry.
...
> insert "permanent" characters into a file, write them in blood? What 
> we want people to do is use the same identifier as the last time they 
Is this a mental exercise in picking language apart and looking for all 
possible ways to misinterpret it, or do you really think that people 
seeing "permanent" are going to think that they have to open the hard 
drive and write on it with an indelible marker?  And do you really 
think that people reading "universally unique" are going to think that 
every time they transmit an atom entry, it's a different entry, and 
thus needs a new ID?  Even you referred to the entry transmitted to two 
clients as "the same atom entry".  Calling it a different entry each 
time it's transmitted is like saying that when you and I look at a 
painting, we're seeing a different painting because different photons 
are bouncing off of it and into each of our eyes.

Given that the details of how a particular server assembles data into 
XML and serves it to clients is an implementation detail beyond the 
scope of the spec (it could be done dynamically, or it could be 
static...), if you are reading that language as referring to "the 
<entry> node that [you] just created in memory", I think you're reading 
the spec incorrectly--that particular point is not a matter of 
ambiguity in the spec language.  Anyway, why would you put an ID into 
an XML document that referred to the state of RAM in your server?  By 
that logic, the client should be generating a new ID for the entry that 
it has in its own memory.

Anyway, details of this particular issue aside, while there is value in 
tightening up the language of the spec to the point where it's 
impossible to come up with an internally consistent yet incorrect 
interpretation of it, we need to take care not to get overzealous and 
end up with a spec that's so verbose that it's unreadable, and thus is 
misinterpreted because people don't spend enough time pondering each 
sentence to figure out what the heck it's trying to say.  And at some 
point, perfect is the worst enemy of good enough.  Unless we really 
think there's a danger of misinterpretation, we'll get more benefit 
from finishing the spec and getting it out than from continuing to 
rework the trivial details of the wording.

While "permanent, universally unique identifier" might perhaps be a bit 
too terse, "an identifier that is used to associate different instances 
of the same resource.  Whenever a resource appears in an Atom Document, 
its identifier SHOULD be the same as any other times it has appeared in 
an Atom Document, and MUST NOT be the same as the identifier currently 
or formerly used for any other Atom resource" may be a bit longer than 
is necessary.  I think making the distinction between the Atom entry 
and the resource that it conveys information about introduces 
unnecessary verbosity to the language.  Borrowing lots of language from 
the current draft:

An Identity construct is an element whose content conveys a permanent, 
universally unique identifier for its parent element.  "Permanent" 
means that the its content MUST NOT change when the parent element or 
any element or document containing it is retransmitted, revised, 
relocated, migrated, syndicated, republished, exported or imported.  
"Universally unique" means that its content cannot have been used as 
the identifier for any other element in any Atom document.  Its content 
MUST be an absolute URI [RFC2396].

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 07 Jan 2005 06:12:02 +0100

On Thu, 6 Jan 2005 21:17:41 -0700, Antone Roundy <[email-masked]>  
wrote:

> is necessary.

Indeed.

> I think making the distinction between the Atom entry and the resource
> that it conveys information about introduces unnecessary verbosity to
> the language.

I agree.

> universally unique identifier for its parent element.  "Permanent" means  
> that the its content MUST NOT change when the parent element or any  
> element or document containing it is retransmitted, revised, relocated,  
> migrated, syndicated, republished, exported or imported.  "Universally  
> unique" means that its content cannot have been used as the identifier  
> for any other element in any Atom document.  Its content MUST be an  
> absolute URI [RFC2396].

Instead of «its content», I think «the identifier» is better. Thus:  
«"Universally unique" means that the identifier cannot have been used as  
the identifier for any other element in any Atom document».

---

From: Eric Scheid <[email-masked]>
Date: Fri, 07 Jan 2005 18:31:15 +1100

> need to focus on the publishing protocol.

Aside from focusing on the publishing protocol, which is well due, what else
happens after we finalise the format spec?

Specifically, what are the IETF hoops that need to be jumped through, and
what periods of diligence/comment are mandated? Or will the document we
settle on at such-n-such date be the one we are completely stuck with for
quite a while until we get around to working on Atom 2.0? If we want to
revise 1.0, do we need to formally establish a new WG through the IETF, or
just carry on from here.

What I'd like to see is one last version of the spec released for trial
deployment (0.9?), in the same sense that 0.3 is out there in the wild, so
that we can see all the mistakes that people make interpreting the spec,
what things work and don't work ... and we can then do a quick spackle and
buff before announcing 1.0. Or is it a trivial matter to revisit the spec in
(say) 3-6 months and quickly burp the baby to get v1.1?

e.

---

From: Graham <[email-masked]>
Date: Fri, 7 Jan 2005 11:21:11 +0000

On 7 Jan 2005, at 4:17 am, Antone Roundy wrote:

> Is this a mental exercise in picking language apart and looking for 
> all possible ways to misinterpret it, or do you really think that 
> people seeing "permanent" are going to think that they have to open 
> the hard drive and write on it with an indelible marker? And do you 
> really think that people reading "universally unique" are going to 
> think that every time they transmit an atom entry, it's a different 
> entry, and thus needs a new ID?

The spec says nothing about what these words mean, and if we're forcing 
people to guess than we are not doing our job. Neither of these words 
inherently mean what the Atom spec wants them to mean. They convey no 
useful information.

> Even you referred to the entry transmitted to two clients as "the same 
> atom entry".

The spec doesn't say identifiers are for identifying the same atom 
entry. If that's what we want it to, it should.

>   Calling it a different entry each time it's transmitted is like 
> saying that when you and I look at a painting, we're seeing a 
> different painting because different photons are bouncing off of it 
> and into each of our eyes.

Let's take photos. The spec does not say that both our photos should 
have the same identifier because they're of the same photo. It does 
imply that we need separate identifiers because they're different 
photos (even if they look the same). The word "permanent" isn't useful 
here.

> Unless we really think there's a danger of misinterpretation, we'll 
> get more benefit from finishing the spec and getting it out than from 
> continuing to rework the trivial details of the wording.

This isn't trivial. The words "permanent" and "universally unique" 
convey as much information to someone who doesn't already know our 
meaning and what the element is for as if we used "lounge chair" and 
"dirigible".

> the identifier for any other element in any Atom document.  Its 
> content MUST be an absolute URI [RFC2396].

"change" - "be different"
"parent element" - what does this mean: Every time I transmit the 
letters "<entry>...</entry>"? You need to refer to the underlying blog 
entry or whatever.

I'm sorry, this once again doesn't convey any useful information as to 
what we mean. I'm not being malicious. As much as Dave Winer thinks so, 
people cannot read the spec writer's mind. The intended meaning need to 
be written on the page.

Graham

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 7 Jan 2005 11:21:22 -0800

>revise 1.0, do we need to formally establish a new WG through the IETF, or

The process is that we (the WG) say "this Internet Draft is done". 
The chairs then communicate this to our AD. He looks it over and 
either asks for changes based on his read-through, or he starts an 
IETF-wide two-week last call. After that IETF-wide last call, either 
he asks us to make changes, or he takes it to the IESG. After their 
review, they either ask us for revisions or they pass it to the RFC 
Editor for publication.

Approximately.

>(say) 3-6 months and quickly burp the baby to get v1.1?

We can revisit whenever we want to. Some WGs do revisions starting 
immediately after the RFC is published, others wait a year or two. 
That is completely up to us, and there are no IETF impediments to 
moving quickly or slowly on revisions.

--Paul Hoffman, Director

---

From: David Powell <[email-masked]>
Date: Fri, 7 Jan 2005 19:32:10 +0000

Just a minor point on that email:

> - an owl file could specify that atom:href is a subproperty of rdf:resource, and so
> alloow us to replace rdf:resource with atom:href

"rdf:resource" is a syntactic element of RDF/XML, not anything that
appears in an RDF model, so I wouldn't have thought that an OWL file
could do syntactic tricks like this?

-- 
Dave

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 9 Jan 2005 01:42:23 -0500

Tim Bray wrote:
> 2. We are close to RSS2 feature-compatibility, we either adopt
> image & enclosure or make a conscious decision not to.
	There are other bits of RSS2 that should be seriously considered --
even if they aren't widely used. For instance, the RSS2 <rating> element
which contains a PICS[1] statement. As far as I know, virtually noone uses
the <rating> tag in RSS2.0. Nonetheless, it would probably be wise to
support such a thing in Atom. As blogging goes "mainstream," we should be
able to show that mechanisms at least exist to do what PICS is attempting to
do...

		bob wyman

[1] http://www.w3.org/PICS/

---

From: Danny Ayers <[email-masked]>
Date: Sun, 9 Jan 2005 14:38:41 +0100

> able to show that mechanisms at least exist to do what PICS is attempting to

The PICS material itself seems very dusty, but ratings came up on the
rss-media@yahoo list and the following links were dropped in:

http://www.icra.org/vocabulary/
http://www.icra.org/projects/quatro/

The fact that the issue was raised on a list related to Yahoo's media
search services does suggest that something like this will be needed
in the not-too-distant future.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Dan Brickley <[email-masked]>
Date: Sun, 9 Jan 2005 15:02:35 -0500

* Bob Wyman <[email-masked]> [2005-01-09 01:42-0500]
> able to show that mechanisms at least exist to do what PICS is attempting to

I agree that it should be possible to do PICS-like stuff in RSS and Atom 
feeds. I'm not sure you need a PICS tag in the core spec though. Various 
folks in Europe and Japan (eg. ICRA, IAJapan) are looking into PICS-like 
functionality in an RDF and XML environment, with use cases that go
somewhat beyond the classic filtering / 'child protection' scenarios 
that dominate public perception of PICS. Historical aside, the original 
name for RDF was PICS-NG, an effort which was merged with Guha and TimBray's 
MCF-in-XML ideas. I'd argue that any PICS-ish functionality in 2005 
can be accomplished using namespaces, and probably using
RDF/XML-oriented namespaces, and that PICS itself is a legacy that
doesn't need to be supported in the core Atom format. Of course if 
there are folks out there who really want to produce and consume 
PICS s-expression syntax in feeds, they can invent a namespace'd 
construct that allows such embedding. There are actually a few things
PICS can do which XML and even RDF/OWL don't do well yet, in particular 
the ability to write a content label with a rule that explains how 
it applies to all documents that share a common base URI. But some of 
are working on an XML/RDF-ization of this. Details hopefully to follow 
soonish...

Dan

---

From: Dan Brickley <[email-masked]>
Date: Sun, 9 Jan 2005 15:04:34 -0500

* Danny Ayers <[email-masked]> [2005-01-09 14:38+0100]
> in the not-too-distant future.

Yeah, that's one of the projects I mentioned (and which currently 
pays for me, via ERCIM, W3C's European host, btw). I have to 
review some new drafts RSN. The basic idea is to finish the technical
migration of PICS stuff to the RDF world, and apply it to quality 
ratings etc rather than just filtering. I'll try to get a feed set up
for the project so folks here can keep an eye on us...

cheers,

Dan

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 09 Jan 2005 16:43:14 +0000

Really? I'd no idea anyone was working on PICS, or had since ... I started
on P3P, circa 1999.

Add me please to your mildly-interested list.

TiA,
Eric