Subject: ServiceElement and other matters

From: James Snell <[email-masked]>
Date: Wed, 2 Feb 2005 23:50:36 -0800

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-masked]

---

From: Eric Scheid <[email-masked]>
Date: Thu, 03 Feb 2005 19:18:04 +1100

On 3/2/05 6:50 PM, "James Snell" <[email-masked]> wrote:

> the user.

The thinking so far has been that you would discard the one which has the
older <updated> datestamp. If the <updated> values are equal, then any
differences were not considered "significant" by the publisher, and so you
can silently discard either one.

You wouldn't merge the versions, apparently.

e.

---

From: Henry Story <[email-masked]>
Date: Thu, 3 Feb 2005 09:52:10 +0100

In RDF/model terms the id is a functional property relating an
Entry/Head and a resource (see my AtomOWL pace) It is not strictly
an identity property (which would require it to be functional, inverse
functional, symmetric and transitive)

This therefore gives you no allowance to merge the entries.

You can sort them by date or other ways if you wish though.

Henry