Subject: AtomPubIssuesList for 2005/02/07

From: Sam Ruby <[email-masked]>
Date: Mon, 07 Feb 2005 12:31:03 -0500

Like I did last time, I am simply scheduling all the open format items 
in the hopes that we can drive this list to zero.

PaceAggregationDocument
PaceAggregationDocument2
PaceAggregationInSeparateSpec
PaceArchiveDocument
PaceClarifyDateUpdated
PaceCollection
PaceCommentFeeds
PaceDatesXSD
PaceEntriesElement
PaceEntryOrder
PaceExtensionConstruct
PaceFeedRecursive
PaceFeedState
PaceFormatSecurity
PaceHeadless
PaceIconAndImage
PaceJoinSectionSixAndTen
PaceLangSpecific
PaceLinkEnclosure
PaceLinkRelVia
PaceMultipleImages
PaceMustBeWellFormed
PaceNoFeedState
PaceOrderSpecAlphabetically
PaceProfile
PaceProfileAttribute
PaceRemoveInfoAndHost
PaceRemoveVersionAttr
PaceRepeatIdInDocument
PaceSecuritySection
PaceTextRules
PaceXhtmlNamespaceDiv

- Sam Ruby

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 Feb 2005 09:50:57 -0800

Thanks, Sam.

Everyone: as Tim and I said last week, this is the last set of Paces 
we are considering for inclusion in the format document. If it's not 
on this list, it isn't considered unless you can show that there is a 
dire technical or security flaw in the document.

Please comment on each Pace separately. Even if you sent in a +1, 0, 
or -1 previously on a particular Pace, send it in again. Hopefully, 
add a short or long comment on why you feel it should or should not 
be considered part of the Atom core. Aggregated lists are cute, but 
greatly hurt the ability to hold a conversation.

Some of the Paces in this last round cover interesting and useful 
topics. Note, however, that "interesting and useful" does not mean 
core to Atom. We don't/can't have a strict definition of what is core 
to the protocol, but after over a year, many of us have a good 
feeling for that.

And, let's remember to have useful Subject: lines, OK?  If a thread 
changes direction, please change the subject line. Thanks!

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 07 Feb 2005 18:08:17 +0000

> PaceJoinSectionSixAndTen

Hi Sam,

I'd like to withdraw this one from consideration, it doesn't fit with 
the IETF way (...mumbles darkly about the ietf way...).

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Mon, 07 Feb 2005 11:03:05 -0800

> in the hopes that we can drive this list to zero.

-1. These should be deferred, see PaceAggregationInSeparateSpec

> PaceAggregationInSeparateSpec

+1. Obviously since I wrote it :-)

> PaceArchiveDocument

+0. We need to clarify 1) requirements for archiving 2) model for 
archiving 3) definition of archiving before we can settle on a syntax. 
I agree with the notion that the current syntax *can* support archiving, 
but as there does not appear to have been significant discussion on it, 
until we agree on requirements/model it is hard to sufficiently analyze.

 > PaceXhtmlNamespaceDiv

+0. Don't know enough about 'em to say.

> PaceCollection

-1. no compelling need for this

> PaceCommentFeeds

+0.5.  I like the general idea, but it may need a bit more fleshing out.

> PaceEntriesElement

-1. no compelling need for this

> PaceEntryOrder

+0. don't care either way

> PaceExtensionConstruct

+1. this is looking good

> PaceFeedState

-1. Just doesn't seem critically necessary.  Also, the hyperbole "If we 
don't specify this, Atom will be unusable for many applications" is 
somewhat annoying.

> PaceHeadless

-0.5. I like the idea of getting rid of head, but not in this way. 
There should be a means of referencing what feed an entry is part of, 
but I'm willing to back off my original assertion that it should be part 
of the core.

> PaceIconAndImage

+0.5. I don't quite understand while these two elements can't be merged? 
It just seems silly to have two separate elements that both specify 
image URIs when the only difference between them is aspect ratio.  It 
would make far more sense to me if we had <link rel="icon" /> <link 
rel="image">.

> PaceLinkEnclosure

+1. just makes sense

 > PaceRemoveInfoAndHost

+0. I don't think it is critical for the core, but whatever.

> PaceMultipleImages

-1. Silly.

> PaceNoFeedState

+1

> PaceOrderSpecAlphabetically

+0

> PaceProfileAttribute

+1.  We need to work out the details between Marks proposal and mine, 
but I think in general this type of mechanism would be much more useful 
than the existing version attribute.

> PaceRemoveVersionAttr

+1. Replace with @profile

> PaceRepeatIdInDocument

-1.  Need to figure out the whole archiving discussion first

- James M Snell

---

From: Henri Sivonen <[email-masked]>
Date: Mon, 7 Feb 2005 21:15:56 +0200

On Feb 7, 2005, at 19:50, Paul Hoffman wrote:

> Even if you sent in a +1, 0, or -1 previously on a particular Pace, 
> send it in again. Hopefully, add a short or long comment on why you 
> feel it should or should not be considered part of the Atom core.

-1 on PaceXhtmlNamespaceDiv

The div is an additional container inside the Text construct container. 
The main purpose of the div is to save one for loop in a 
document-tree/pull-based client or, alternatively, to give a false 
sense of correctness in tag soup concatenation-based clients. IMO, 
neither rationale warrants a meaningless element inside a Text 
construct.

(Noting that the Pace was retracted by the original author.)

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Sam Ruby <[email-masked]>
Date: Mon, 07 Feb 2005 14:38:48 -0500

Henri Sivonen wrote:
> document-tree/pull-based client or, alternatively, to give a false sense 
> of correctness in tag soup concatenation-based clients. IMO, neither 
> rationale warrants a meaningless element inside a Text construct.
> 

It was retracted due to a perceived lack of interest - at that point it 
was a two party dialog between yourself and that author.

Since then a number of folks (myself included) expressed support for 
this Pace, I reopened it with an email to the list, and I will now 
reiterate my support now with a +1.

There are a number of issues that this resolves, such as whether the div 
element itself is to be considered part of the content in protocol POST 
methods.  If they are not, you will tend over time to see multiple such 
wrappings.

-Sam Ruby

---

From: Graham <[email-masked]>
Date: Mon, 7 Feb 2005 20:03:43 +0000

On 7 Feb 2005, at 7:38 pm, Sam Ruby wrote:

> There are a number of issues that this resolves, such as whether the 
> div element itself is to be considered part of the content in protocol 
> POST methods.  If they are not, you will tend over time to see 
> multiple such wrappings.

+1, and not just because it will make my life easier.

Graham

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 07 Feb 2005 21:08:11 +0100

> -1 on PaceXhtmlNamespaceDiv

-1 from me as well. It is hack which might be useful for publishing 
systems (and perhaps aggregators) who do not use the right tools to 
generate a valid Atom file anyway.

-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 Feb 2005 00:06:51 +0100

> generate a valid Atom file anyway.

Same here: -1

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Roger B." <[email-masked]>
Date: Mon, 7 Feb 2005 17:42:47 -0600

I'm +1 when wearing my aggregator hat, and indifferent from a
publishing perspective.

--
Roger Benningfield
JournURL

---

From: Sam Ruby <[email-masked]>
Date: Mon, 07 Feb 2005 18:55:07 -0500

>> generate a valid Atom file anyway.

Can I get one of you three to mock up what Tim's feed should look like?

http://www.imc.org/atom-syntax/mail-archive/msg12902.html

- Sam Ruby

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:25:44 +1100

+1

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:11:07 +1100

+1

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:37:37 +1100

> PaceJoinSectionSixAndTen

-1

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:24:12 +1100

+1

yeeouch - I had no idea just how extensive the difference in opinions as to
what a <feed> represents.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 12:02:07 +1100

+1

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:33:31 +1100

-1

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:37:07 +1100

+1

+1 to renaming atom:image to atom:logo

> PaceMultipleImages

-1 : multiple language variants of anything seems to be well-kyboshed
anywhere in atom

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:47:47 +1100

+1

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:54:49 +1100

+1

the alternative proposed so far contains instructions of traversal of feed
documents ... when instead there may be other mechanisms.

For example: Bob could work up a system of pushing a series of entries in
response to a request for "all entries between date X and date Y".

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:23:51 +1100

-1

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:30:31 +1100

-1

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:24:17 +1100

> PaceClarifyDateUpdated

+1. 

atom:updated is not atom:modified or dc:modified, and we need to guard
against that if the special semantics of atom:updated are not be smothered
under a flood of atom:modified pollution.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:46:36 +1100

> PaceLinkEnclosure

+1 to @rel="enclosure", or @rel="attachement" as some want it

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 12:01:01 +1100

> PaceRemoveVersionAttr

-0

I suspect there are good social reasons to keep @version

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:32:07 +1100

> PaceFeedState

-1 to all the traversal shenanigans being in the core

+1 to link/@rel=[next|prev|self]

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:55:53 +1100

+1

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:21:49 +1100

> PaceCommentFeeds

+1 to link/@rel="comment"

-1 to feed/head/content

+0 to feed/head/summary -- this could be informative even for non-comments
feeds, a descriptive meta-data element

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:57:50 +1100

+1

I'm happy with allowing multiple entries with the same ID in the one <feed>
instance. Aggregators already must handle the case of seeing the same ID in
some way, since that ID could quite reasonably have been in a previous
edition of the <feed> resource.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:24:06 +1100

-1

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:51:23 +1100

> PaceMustBeWellFormed

-1 - needs to be re-written to avoid use of "well-formed" which has a
specific meaning to some religious fanatics ;-)

+1 to the general intent of this pace: explaining how publishers might get
tripped up by the obscurities of technology and render their feed "broken"

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:44:26 +1100

> PaceLangSpecific

+1, but also needed for atom:generator

hmmm ... if we have xml:lang on <content>, we are going to also need
@hreflang for <content src="..." />, because while some types of referenced
content can have the language attached, at type="text/plain" cannot.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:14:17 +1100

-1

this looks like a backdoor to feeds in feeds.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 11:22:43 +1100

+1

---

From: Robert Sayre <[email-masked]>
Date: Mon, 07 Feb 2005 22:00:14 -0500

+1, there's no reason for atom:head.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 14:48:45 +1100

-1 atom:feeder is ugly

---

From: Henri Sivonen <[email-masked]>
Date: Tue, 8 Feb 2005 07:03:26 +0200

> Can I get one of you three to mock up what Tim's feed should look like?

<a:feed xmlns:a='http://purl.org/atom/ns#draft-ietf-atompub-format-04' 
version='draft-ietf-atompub-format-04 : do not deploy' 
xmlns='http://www.w3.org/1999/xhtml' xml:lang='en-us'>
...
  <a:entry>
...
   <a:content type='XHTML'>I was in the drugstore picking up a 
prescription and wandered into the computer section, where I found 
myself impulse-buying <a href='http://dvforge.com/themousebt.shtml'>The 
Mouse BT</a> from some outfit
...

OR

<a:feed xmlns:a='http://purl.org/atom/ns#draft-ietf-atompub-format-04' 
version='draft-ietf-atompub-format-04 : do not deploy' 
xmlns:h='http://www.w3.org/1999/xhtml' xml:lang='en-us'>
...
  <a:entry>
...
   <a:content type='XHTML'>I was in the drugstore picking up a 
prescription and wandered into the computer section, where I found 
myself impulse-buying <h:a 
href='http://dvforge.com/themousebt.shtml'>The Mouse BT</h:a> from some 
outfit
...

OR

<feed xmlns='http://purl.org/atom/ns#draft-ietf-atompub-format-04' 
version='draft-ietf-atompub-format-04 : do not deploy' 
xmlns:h='http://www.w3.org/1999/xhtml' xml:lang='en-us'>
...
  <entry>
...
   <content type='XHTML'>I was in the drugstore picking up a 
prescription and wandered into the computer section, where I found 
myself impulse-buying <h:a 
href='http://dvforge.com/themousebt.shtml'>The Mouse BT</h:a> from some 
outfit
...

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: James M Snell <[email-masked]>
Date: Mon, 07 Feb 2005 21:38:46 -0800

Agree, feeder is ugly. but head should still go away.  My preference 
would be a link based alternative.

<feed>
   ...
   <entry>
     ...
     <link rel="feed" href="..." />
   </entry>
</feed>

- James M Snell

---

From: Eric Scheid <[email-masked]>
Date: Tue, 08 Feb 2005 18:03:38 +1100

+1

---

From: David Powell <[email-masked]>
Date: Tue, 8 Feb 2005 08:43:21 +0000

> content can have the language attached, at type="text/plain" cannot.

text/plain can have a Content-Language header though - is that compatible with
xml:lang?

-- 
Dave

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 Feb 2005 13:25:32 +0100

> http://www.imc.org/atom-syntax/mail-archive/msg12902.html

I'm not sure I understand this request. We're not asking Tim or anybody 
else not to use <div> elements, we're asking not to be forced by the 
spec to select a specific way to emit XHTML when many others do as well.

So, this is a -1 on forcing feed creators to use a very specific 
serialization format.

Best regards, Julian

---

From: Henri Sivonen <[email-masked]>
Date: Tue, 8 Feb 2005 14:32:32 +0200

On Feb 8, 2005, at 07:03, Henri Sivonen wrote:

> myself impulse-buying <a 
> href='http://dvforge.com/themousebt.shtml'>The Mouse BT</a> from some 
> outfit
> ...

OR (even less impact on string concatenators):

<feed xmlns='http://purl.org/atom/ns#draft-ietf-atompub-format-04' 
version='draft-ietf-atompub-format-04 : do not deploy' 
xml:lang='en-us'>
...
  <entry>
...
   <a:content type='XHTML' 
xmlns:a='http://purl.org/atom/ns#draft-ietf-atompub-format-04' 
xmlns='http://www.w3.org/1999/xhtml'>I was in the drugstore picking up 
a prescription and wandered into the computer section, where I found 
myself impulse-buying <a href='http://dvforge.com/themousebt.shtml'>The 
Mouse BT</a> from some outfit
...

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Henri Sivonen <[email-masked]>
Date: Tue, 8 Feb 2005 14:41:20 +0200

> text/plain can have a Content-Language header though - is that 

For practical purposes, yes. In theory, the semantics are different.

xml:lang specifies the language of the content but Content-Language 
describes the language of the intended audience.

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Sam Ruby <[email-masked]>
Date: Tue, 08 Feb 2005 08:44:02 -0500

> So, this is a -1 on forcing feed creators to use a very specific 

This Pace does *not* force feed creators to use a very specific feed format.

Anne had this right... if this Pace is adopted, then the div is part of 
the format.  Otherwise, it is part of the content.

In other words, if Tim's content has a <div> element that he wishes to 
syndicate, he would simply nest that div.  This would be rare.

As it stands, the content that Tim is syndicating does not match the 
content on his site.

- Sam Ruby

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 8 Feb 2005 08:39:42 -0500

James M Snell wrote:
> My preference would be a link based alternative.
><feed>
>   ...
>   <entry>
>     ...
	I'm tired of arguing this one, so, I'm just going to say this one
more time and leave it at that.
	Linking to the feed is not an acceptable solution. It must be
possible to embed feed metadata in an entry in a feed and in an Entry
document. 
	Users and their news aggregators expect to have access to source
feed title, author, etc. when entries or lists of entries are displayed. If
the feed metadata is not in the entries, then it will have to be fetched
before entries can be displayed to the user. Thus, we should expect that
whenever a feed is received that contains links to feeds, the aggregators
will immediately generate a storm of HTTP request to pull down the full
feeds which are linked to simply in order to extract the feed titles and
other metadata. The result will be bursts of network traffic. Most of the
bandwidth consumed will be an absolute waste. (i.e. Many feeds in the wild
today are as large as 100K bytes. You're suggesting a design that requires
all 100K bytes to be pulled down in order to extract a few bytes of title
data. This is silly.)
	If Atom drops HeadInEntry (or the alternative equivalent mechanisms
such as feeder) and replaces it with a link to feed, we at PubSub will
simply not be able to use Atom as defined. Other providers of aggregators,
search engine results, synthetic feeds, etc. will come to the same
conclusion in time.
	Have a good day. I'm sure you'll all be pleased to know that I won't
be bothering you about this in the next few days. Do what you will...

		bob wyman

---

From: Walter Underwood <[email-masked]>
Date: Tue, 08 Feb 2005 09:42:20 -0800

+1

The feed document *must* be standalone. Everything required to
interpret the feed has to be in the feed.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: James M Snell <[email-masked]>
Date: Tue, 08 Feb 2005 09:37:05 -0800

Well, I ain't gonna argue the point, but I'm going to stick by the 
assertion that feeder/head is ugly.  Any use of this stuff I plan to 
make can live equally well with either approach.

- James M Snell

---

From: Graham <[email-masked]>
Date: Tue, 8 Feb 2005 18:39:33 +0000

> this looks like a backdoor to feeds in feeds.

-1, agreed.

Graham

---

From: Henry Story <[email-masked]>
Date: Fri, 11 Feb 2005 23:11:07 +0100

>> PaceRepeatIdInDocument

+1 over any attempt to clearly specify that it is not allowed
    to be repeated.

It is better to be clear than to be ambiguous. But it is better to
be ambiguous than to close the doors on rich possibilities just for the
sake of clarity.

This proposal is clearly better than the counter proposal asking
for a limitation:
   - the counter proposal is forced to invent all kinds of new entities
    such as archive feeds to accomplish the goals of the charter. These
    are not needed either by the ambiguous current spec, or of course
    by one that applies this proposal
   - the counter proposal is making life more difficult for deployers
    of atom who instead of just being able to paste their new entry into
    a feed document must now verify that that document not have another
    entity with the same id.

Henry Story

---

From: Sam Ruby <[email-masked]>
Date: Tue, 22 Feb 2005 10:31:35 -0500

As Tim noted[1], the collection paces appear to be in a bit of a 
disarray.  His suggestion that the authors address this over the past 
few days did not achieve the desired result.  Given this, I am going to 
tentatively declare all the collection paces which contain TBDs, XXXs, 
and questions in square brackets as abandoned and therefore recommended 
for closure.

So, currently under discussion:

   PaceCollectionIdiom
   PaceCollectionSyntax
   PaceEntryQuery

And, recommended for closure:

   PaceDateRangeCollections
   PaceRangesAndSubsets
   PaceReturnCollNewestToOldest
   PaceServerCollectionSubsets

- Sam Ruby

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 22 Feb 2005 08:44:39 -0800

>   PaceServerCollectionSubsets

Right. Because these Paces are all protocol-related, the discussion 
of them should be be on the atom-protocol mailing list. (See 
<http://www.imc.org/atom-protocol/> if you need tracking/subscribing 
information.)

This list should still be focused on the format draft. As our 
document editors toil away diligently, we can still offer editorial 
suggestions. This is also a reasonable time to start creating format 
extensions  and talking about them here.

--Paul Hoffman, Director

---

From: Ezra Cooper <[email-masked]>
Date: Tue, 22 Feb 2005 10:09:50 -0800

> and questions in square brackets as abandoned and therefore recommended

Sorry that I've been moving slowly on this. Just been a bit busy the past
week.
 
>    PaceServerCollectionSubsets

I don't object to these being closed, but I'd like to have the chance to
make a new proposal which would be an alternative to PaceEntryQuery.

My proposal will:

  * provide for collections, obeying the "slash semantics"
  * allow for date-range queries over any (top-level) collection or
sub-collection
  * not provide for index-based ranges, or other kinds of searches.

If I can have this done by the end of the day, could we discuss it in this
round?

Ezra

---

From: Sam Ruby <[email-masked]>
Date: Tue, 22 Feb 2005 13:52:09 -0500

> If I can have this done by the end of the day, could we discuss it in this

Yes.

- Sam Ruby

---

From: Ezra Cooper <[email-masked]>
Date: Tue, 22 Feb 2005 17:34:48 -0800

I've just posted PaceSliceAndDice. This describes a way for clients and
servers to break large collections into small pieces.

The basic ideas here are not new to the group, but the language is more
precise and I've thrown in a mechanism that helps to compose
"subcollections" with "time-interval queries." I'm assuming that we'll use
the same syntax to collect entries, templates, "resources", etc.

In this proposal, none of the item-specific data is included in the
collection document (you have to dereference the individual URLs), but we
should probably address that in an independent proposal.

Suggestions on how to make this more clear are heartily welcomed. Also,
there are lots of details that could be changed without damaging the
proposal, so I'll be interested in your criticisms.

It should now be safe to close these, which I originally authored:
    PaceDateRangeCollections
    PaceRangesAndSubsets
    PaceReturnCollNewestToOldest
    PaceServerCollectionSubsets

Thanks,
Ezra

---

From: Martin Duerst <[email-masked]>
Date: Wed, 23 Feb 2005 10:26:12 +0900

At 01:44 05/02/23, Paul Hoffman wrote:

 >This list should still be focused on the format draft. As our document 
editors toil away diligently, we can still offer editorial suggestions. 
This is also a reasonable time to start creating format extensions  and 
talking about them here.

Hello Paul,

Will there be a two-week WG last call for the Atom format
document, as usual with IETF WGs?

Regards,    Martin.

---

From: Robert Sayre <[email-masked]>
Date: Wed, 23 Feb 2005 00:05:09 -0500

> This is also a reasonable time to start creating format extensions  and 

Here's one that's sort of done:
http://fotonotes.net/spec/index.cgi?FotoNotesSpecification

This is what will carry Flickr annotations, and they do it with Atom and 
RDF. They made a few mistakes. One of them centered around the purpose 
of atom:id. That means *smart people miss the point*, because it's a 
subtly different than RSS. I think starting the example atom:id with 
"urn:uuid" instead of "vemmi://" would help quite a bit.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Wed, 23 Feb 2005 19:17:03 +0000

On 23 Feb 2005, at 5:05 am, Robert Sayre wrote:

> This is what will carry Flickr annotations, and they do it with Atom 
> and RDF. They made a few mistakes. One of them centered around the 
> purpose of atom:id. That means *smart people miss the point*, because 
> it's a subtly different than RSS. I think starting the example atom:id 
> with "urn:uuid" instead of "vemmi://" would help quite a bit.

Care to elaborate on what the problem was?

Graham

---

From: Robert Sayre <[email-masked]>
Date: Thu, 24 Feb 2005 10:45:48 -0500

> Care to elaborate on what the problem was?

"<id>...</id> Authorative location of original copy or published copy of 
image.

       <id>http://rowlff.dotgeek.org/plugin/demoimage.jpg</id>

When used within an <entry> tag, <id> defines the unique URL to to that 
<entry>. Note the "1@" in the following <id> tag:

       <id>http://rowlff.dotgeek.org/plugin/[email-masked]</id>"

Basically, they think atom:id is similar to <guid isPermaLink="true">.

Robert Sayre