Subject: Re: What is Atom for?

From: [email-masked]
Date: Thu, 16 Dec 2004 17:06:58 EST

In a message dated 12/16/2004 8:04:52 PM GMT Standard Time, 
[email-masked] writes:

> [email-masked] wrote:
> >
> >I can write http://www.tfosorcim.org/blog/ which is a URL which 
> "represents" 
> >my blog.
> 
> OK, that got my attention.  In particular, this entry:
> 
> http://www.tfosorcim.org/archives/000308.html
> 
> What you noted there gives you a bit of credibility in my eyes. 
> Hopefully, you will get a chance at some point to give the Atom 
> specification as thorough of a reading.

Sam,

Writing a chapter about a spec is a great way to find out what is clear and 
what's not.

That same intended thoroughness of reading was what stimulated the original 
question about Atom in this thread. :)

Just as in RSS 2.0 some things didn't tie up neatly so the same phenomenon is 
in evidence in the Atom Charter and draft specification. ... Maybe you didn't 
want to hear that, though. :)

I have already mentioned some of the lack of clarity in the Charter. Let me 
also make brief comments on the Introduction of the October draft.

It states:
"Atom is an XML-based document format intended to allow lists of related 
information, known as "feeds", to be synchronised between publishers and 
consumers."

That isn't quite right. The XML-based document format is only one part of 
"Atom", at least that's what the Charter indicates. So maybe start the quote as, 
"The XML-based document format defined in this document is one part of the 
[x-part?] Atom specification. .... "

The next sentence currently reads:
"Feeds are composed of a number of items, known as "entries", each with an 
extensible set of attached metadata."

That isn't quite right, either. It doesn't mention feed metadata. I would 
suggest that "A feed is composed of metadata about the feed, together with a 
number of items, known as "entries", each of which may contain or reference 
content and have its own set of metadata" might be better.

My most substantive concern about the Atom Syndication Format draft document 
is the intention to muddy the concepts of the information set and the 
serialized document. That seems to me to be a recipe for lack of clarity in multiple 
places. Yes, it will be harder to draft the document to clearly distinguish the 
description of the infoset (is that the "conceptual model"?? of the Charter) 
from the serialised document. But it would reduce the likelihood of embedded 
ambiguity in the Atom specification documents, in my opinion.

Another significant concern is the lack of clear specification, as far as I 
can see, of the "conceptual model", if by that we mean the kind of thing that 
was labelled as "Data Model" in the slide set to which you pointed me.

The archive aspect of Atom seems to me to be seriously underspecified at 
present. Having not had time to closely follow discussions in recent weeks I may 
have missed something that adds to what I am aware of in that regard.

But it's not really entirely fair to probe a relatively early draft in that 
way.

> 
> Meanwhile, I'll suggest the following as a place to start the 
> conversation on your original question (as reflected in the subject line):
> 
> http://intertwingly.net/slides/2003/xmlconf/
> 
> Many of the specifics (example: syntax of link elements) have changed 
> since that time, but the issues that motivated each change still remain.

You found, by attempting to implement them, that the existing specs contain 
ambiguities. I would concur with that finding in the context of trying to write 
about them to interpret their meaning for a reader. At times when writing I 
was very consciously "interpreting". In many practical situations (for my 
purpose) it didn't matter too much since many aggregators are permissive.

With respect to archiving, one serious question I have relates to the 
permanency/uniqueness of URIs. Having had a domain effectively hijacked some time 
back (my fault for not watching the renewal date) a URI (a URL, to be specific) 
that was "mine" then led to different content from a different person. A URI 
plus timestamp seems to me to be more likely to be unique and worth using a 
basis for archiving.

I noticed one interesting point in your Summary slide: "content is a rich 
source of metadata". I wonder if the following perspective is not more true: 
"data and metadata are often intermixed".

If, as the slide set suggests, your aim for Atom is to have a more 
unambiguously specified set of specification documents than for any previous information 
feed specification, then my opinion is that there is quite a way to go. I say 
that having worked word by word through RSS 0.91, 0.92, 1.0 and 2.0 in the 
very recent past. Atom may have the potential to be clearer but, IMHO, it needs 
considerable further work to achieve the clarity that I think is your hope for 
it.

Andrew Watt