Subject: Spec explanations for Pebble?

From: Carey Evans <[email-masked]>
Date: Fri, 12 Aug 2005 20:16:48 +1200

Simon Brown has upgraded the Atom feed generated by his Pebble weblog
software (http://pebble.sf.net/) to draft-10.  I've reported a few
problems with it, based on my understanding of the spec, but there are
a couple of points that don't seem to be directly addressed.  See:

  http://www.simongbrown.com/jira/secure/ViewIssue.jspa?key=PEB-266

First, where does the spec actually say that the atom:id shouldn't
change if the blog moves to a different domain?  I think that if the
URL of the blog changes, it means that the Atom Feed Document has been
relocated so the ID should stay the same, but Simon doesn't see this
in the spec.

Second, what sort of values should be used for the scheme attribute on
the category?  Looking at http://www.tbray.org/ongoing/ongoing.atom as
an authoritative example, it seems that the scheme should be the same
for all categories, but Pebble uses the URL of the individual category
page.  The spec doesn't say, so does it matter?

Can the list offer some advice?  Thanks.

(Reposted because the original didn't get through; my apologies for
any duplicates. Look out for the Gmail Reply-To.)

-- 
http://carey.geek.nz/

---

From: Graham Parks <[email-masked]>
Date: Fri, 12 Aug 2005 09:55:19 +0100

> relocated so the ID should stay the same, but Simon doesn't see this

Section 4.2.6, paragraph 3:

   "an atom:id element pertains to all instantiations of a particular
    Atom entry or feed; revisions retain the same content in their
    atom:id elements. It is suggested that the atom:id element be
    stored along with the associated resource."

If an Atom document is a feed of the same blog, then even if the blog  
has moved, the id should stay the same. What makes you think otherwise?

> page.  The spec doesn't say, so does it matter?

Section 4.2.2.2:

    "The "scheme" attribute is an IRI that identifies a  
categorization scheme."

"categorization scheme" means the system used to categorize entries.  
Presumably each blog has its own system for doing so, so the scheme  
attribute should be the same for all posts from the same blog, and  
unique to the blog.

Graham

---

From: Tim Bray <[email-masked]>
Date: Fri, 12 Aug 2005 06:52:28 -0700

On Aug 12, 2005, at 1:55 AM, Graham Parks wrote:

> "categorization scheme" means the system used to categorize  
> entries. Presumably each blog has its own system for doing so, so  
> the scheme attribute should be the same for all posts from the same  
> blog, and unique to the blog.

Mostly agree.

Except for, a bunch of blogs might agree to share a categorization  
scheme, so probably not "unique to each blog".

But I suspect that the notion of "categorization scheme" is  
underdefined enough that if someone wanted to use different URIs for  
each page like the example Carey cited, that's really dumb but not  
actually illegal. -Tim

---

From: Graham <[email-masked]>
Date: Fri, 12 Aug 2005 15:50:58 +0100

On 12 Aug 2005, at 2:52 pm, Tim Bray wrote:

>> the scheme attribute should be the same for all posts from the  
>> same blog, and unique to the blog.
>

Fair point.

btw, Doesn't scheme and term require atom:id style discussion of  
equivalence to be useful?

Graham

---

From: Walter Underwood <[email-masked]>
Date: Fri, 12 Aug 2005 09:03:02 -0700

> scheme, so probably not "unique to each blog".

For example, as libraries start delivering literature monitoring with
feeds, we'll see LCSH or some other standard category system in those.

wunder
--
Walter Underwood
Principal Software Architect, Verity

---

From: Simon Brown <[email-masked]>
Date: Sat, 13 Aug 2005 08:34:49 +0000 (UTC)

> has moved, the id should stay the same. What makes you think otherwise?

That same paragraph starts, "When an Atom Document is relocated, migrated,
syndicated, republished, exported or imported, the content of its atom:id
element MUST NOT change.". For me, this paragraph talks about the *Atom
Document* moving, rather than the content that it represents (i.e. a blog). Mark
Pilgrim has a great article about Atom IDs and towards the end of it goes on to
talk about the same entry in multiple feeds
(http://diveintomark.org/archives/2004/05/28/howto-atom-id#multiple), although
that's not what I'm talking about here.

Just to quote an example, Tim is currently using URL based Atom IDs, such as :

<id>http://www.tbray.org/ongoing/</id>
<id>http://www.tbray.org/ongoing/When/200x/2005/08/09/Web-2.0</id>

If Tim *moves* his blog to www.timbray.com/ongoing, would you expect his Atom
IDs to remain the same? Spec aside, this has some implications for storing Atom
IDs next to content they identify, which I imagine doesn't happen in most CMS
tools at the moment.

> attribute should be the same for all posts from the same blog, and  

The categorization scheme is a little confusing, although looking at Tim's feed
and a few others has cleared up in my mind what I should be using. Basically, I
was using this

<category term="pebble" label="pebble"
scheme="http://www.simongbrown.com/blog/tags/pebble" />

rather than this (notice the shorter scheme)

<category term="pebble" label="pebble"
scheme="http://www.simongbrown.com/blog/tags/" />

Are there any recommendations as to that the scheme attribute should be and what
it might be used for?

Simon

---

From: Tim Bray <[email-masked]>
Date: Sat, 13 Aug 2005 07:37:58 -0700

On Aug 13, 2005, at 1:34 AM, Simon Brown wrote:

> IDs to remain the same?

Absolutely, otherwise everyone who subscribes to me is going to see  
all the same old articles again, exactly what atom:id exists to  
prevent.  The fact that I use HTTP URIs for identifiers reflects my  
belief that good Web citizenship requires that once something is  
published and its URI widely disseminated, it should never ever be  
moved; so in my case this scenario is unlikely to arise. -Tim

---

From: Walter Underwood <[email-masked]>
Date: Sat, 13 Aug 2005 10:38:17 -0700

> IDs next to content they identify, which I imagine doesn't happen in most CMS

Of course they stay the same. At the risk of being rude, "duh".

It is an ID, not an href. ID, ID, ID.

If we need to clarify the spec further, though, let's do it now.
I don't mind specifically saying that the ID stays the same when
content is relocated.

wunder

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 14 Aug 2005 03:40:33 +0200

* Tim Bray <[email-masked]> [2005-08-13 16:50]:
> The fact that I use HTTP URIs for identifiers reflects my
> belief that good Web citizenship requires that once something
> is published and its URI widely disseminated, it should never
> ever be moved; so in my case this scenario is unlikely to
> arise.

I don’t know if you can reflect any belief by your choice of
scheme for your atom:id values, though. As far as the consumer is
concerned, the string is opaque and meaningless anyway, so
whatever you put in there matters naught as long as it’s a URI.

Therefore, *I* believe that authors of database-based CMS
software of any form should be advised to use UUIDs, because a)
it is instantly obvious that UUIDs have to be stored with their
respective entry, so there’s no temptation to derive the ID
dynamically from any other part of the data, and b) UUIDs are
fixed-size and the binary form is very compact, which makes them
extra easy to deal with in a database.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 14 Aug 2005 03:45:15 +0200

* Simon Brown <[email-masked]> [2005-08-13 11:00]:
> If Tim *moves* his blog to www.timbray.com/ongoing, would you
> expect his Atom IDs to remain the same?

Yes. That’s what the spec says and that’s what IDs are for: they
*NEVER change*. Period. Regardless of what else you do with your
content, the ID of the same entry is *ALWAYS* the *SAME* it has
had since the moment it was created.

> Spec aside, this has some implications for storing Atom IDs
> next to content they identify, which I imagine doesn't happen
> in most CMS tools at the moment.

That’s a different matter, and one we need to educate producers
about. IDs should always be generated once, at the time of entry
creation, and then stored alongside the entry, for eternity –
unchanging.

Regards,