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]
