Ok, so I'm an Atom end-user who has been monitoring the fringes of the effort to define the spec and am now spending some time going through the near-finished product to see what issues I can spot. That said, likely just as most potential atom-end-users, I am not aware of the full history of the various conversations and debates that may have gone on previously regarding any single part of the spec.
In reading through the spec, several things stick out: 1. Service Construct. While I understand what the Service Construct is trying to do, and I agree that it is needed, it does not seem to me to be something that rightfully belongs in the "core" Atom syntax. Rather, it seems better placed as an Atom syntax extension introduced by the Protocol specification. The rationale is simple: The Protocol spec should deal with all service related issues, including any extensions to the core that are necessary to communicate protocol related information. If I were putting this stuff together, I would move the Service Construct to the protocol spec. 2. Entry id's. Ok, so they are supposed to be "universally unique". That's all good and fine. But what if... hypothetically... my Atom reader gets two copies of the same Entry with different metadata. They are the same entry because they have the same id. One of the versions of the entry differs from the other in that some feed aggregator somewhere added some additional pieces of metadata to it. Do I: a) silently reject one of the entries, b) merge the metadata of the two entry instances into a single logical entry, c) throw up on the user. Case in point where this might be an issue: Suppose an entry in a feed that references a standalone entry document for the same entry. <!-- feed.xml --> <feed> <entry> <title>My Entry</title> <id>uri:abc</id> <link rel="alternate" href="entry.xml" type="application/atom+xml" /> </entry> </feed> <!-- entry.xml --> <entry> <id>uri:abc</id> <content>Hello There</content> </entry> Is this legal? If it is, how should clients handle this situation? Do the two separate entry elements merge to form a single logical entry or does one replace the other? 3. I know this has been discussed elsewhere because I've seen a couple of recent posts about it. The version attribute just seems hokey. It doesn't add any value beyond what the XML namespace already provides. Just one guys opinion. Take it for what it's worth. 4. What the heck is an introspection document? I actually do know what it is, but the current doc doesn't say. This needs to be fleshed out obviously. Of course, if #1 above is addressed, this ceases to be a problem. :-) This is what I came up with on my first full read through of the -05 draft. Maybe more later. -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]