Subject: Re: Identity conundrum

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 02 Aug 2004 12:15:49 +0200

On 31 Jul 2004 12:12:13 -0500, Ken MacLeod <[email-masked]> wrote:

>   <feed>
>     <entry>
>       <id>urn:myentry</id>
>       <version:id>urn:myentry:2</version:id>
>       <content>Hello There</content>
>     </entry>
>     <entry>
>       <id>urn:myentry</id>
>       <version:id>urn:myentry:1</version:id>
>       <content>Hello</content>
>     </entry>
>   </feed>

My take on this is that both views should be supported in atom:id. Since  
the simplest of the two views is the one that «flattens» all instances,  
e.g. the current view in blog tools, this view should be the one supported  
in Atom Core.

The more advanced view can then be layered on top of the basic view as an  
extension. This can be achieved by telling consumers what profile a feed  
conforms to, and by reading the specification for that profile, you  
understand the semantics of the Atom elements, which will still reside in  
the core Atom namespace.

Such a profile could for example re-define the semantics of atom:id and  
atom:issued from referring to the latest (or first) version of an entry,  
to «this instance». The rules for atom:id could also be changed into  
requiring a given ID scheme, or at least a scheme that supports  
versioning. For example:

   <feed>
     <profile xmlns="http://purl.org/atom/ns#versioning" />
     <entry>
       <id>urn:myentry:2</id>
       <content>Hello There</content>
     </entry>
     <entry>
       <id>urn:myentry:1</id>
       <content>Hello</content>
     </entry>
   </feed>

This would still make the feed parsable by clients that don't understand  
the «versioning» profile, and the semantics won't be so off that the data  
is useless. Everything still works just fine, and a client that doesn't  
support the «versioning» profile will at the worst display a versioned  
entry over again, which is what the author would want to happen, anyway  
(re the 'Updated' element).

What's great about this approach is that you can use the same core Atom  
elements to mean slightly different things in a given profile, and don't  
have to clutter the feed with extension namespaces when what you're doing  
is just refining Atom's core semantics. If you're really extending the  
format, the elements should of course reside in extension namespaces.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»