RE: Feed Paging in 5023 and 5005

[Davis_Cornelia@xxxxxxx]

Hi Brian - thanks for the response - definitely helpful.  A couple of
follow ups:

You said:

> Collection feeds should always be ordered by app:edited. If you want a
> feed ordered in a different way, you can do so with a different feed
> (perhaps linked from the service document or from the collection feed)

Okay, so I'm trying to grock what it really means to have a feed that is
not a collection feed.

* I definitely loose the guarantee of app:edited sorting.  Given that I
am looking to avoid that feature I'm okay with this.
* The feature I'd rather not loose is this one:  If I've designated
something as a collection feed then I know that I can list the
collection members with a GET to the collection URI, and I can create a
member resource by issuing a POST to that collection - with the nice
little guarantee that if I post a non-entry resource that a media link
entry resource will be created in addition to the media resource.  Ouch
- that is something I'd rather not have to give up.  A work around would
be to define a link relation type that has those semantics associated
with it, as you suggest, and because I can add foreign markup to a
service doc I can add such links, even in the context of a particular
workspace.
* And finally, I give up all of the defined syntax on how collections
are specified in service documents and the associated semantics when I
am interacting with a collection - particularly the associated
categories and allowed media types.  Again, I can rebuild a similar
structure - if I'm not mistaken even as child elements of the link
relation described in the previous step - again I'll have to formally
express the syntax and semantics.

So the short of it is, if a want something that looks like a collection
feed in every way EXCEPT the ordering then I need to build out similar
structures, define syntax and semantics.  A shame but I suppose I have
to live with it -it's doable.  Thanks again for the insight you have
given - helps a ton.

On the matter of element ordering in XML, the issue is that while the
XML spec specifically says that attributes are unordered, it does not
specifically say that elements are ordered.  For a good description of
the problem see:
http://www-128.ibm.com/developerworks/xml/library/x-eleord.html.  The
section that succinctly states the problem is aptly titled "Lawyer among
the specifications" (ugh - I think that says that I am dangerously close
to playing the lawyer role here).  I agree with the author of this paper
that I don't actually know of any XML processors that don't preserve the
document order, hence the huge body of applications that depend on
document order today (and a perhaps equally huge body where the order
really doesn't matter).  I'm marginally okay with this assumption though
have to admit that when I think of parallelization I get a bit
uncomfortable.  In the case of collection feeds it is not an issue so
long as we follows your suggestion that non-identical app:edited values
are avoided AND we make sure to return app:edited.

Again, thanks!  

Cornelia 

-----Original Message-----
From: owner-atom-protocol@xxxxxxxxxxxx
[mailto:owner-atom-protocol@xxxxxxxxxxxx] On Behalf Of Brian Smith
Sent: Thursday, March 20, 2008 7:39 PM
To: Davis, Cornelia; atom-protocol@xxxxxxx
Subject: RE: Feed Paging in 5023 and 5005


Davis_Cornelia@xxxxxxx <mailto:Davis_Cornelia@xxxxxxx> wrote:

> * These link relations are also addressed in 5005
>   and I'll note describing less specific semantics:

Right. AtomPub has stricter restrictions on the use of those link
relations, but only for collection feeds. 

> Does looking at the IANA registry of link relations
> tell me anything about what the semantics for a
> link relation are? 

As you have seen, many link relations are vaguely defined in the
registry. When you need to understand more specific semantics, look at
the specific application's specification.

> As you can I'm sure conclude, I am interested in
> feeds that are ordered along an axis other
> than time. 
>
> Oh, and for 5023 I assume the intent with
> ". MUST contain the most recently edited member ."
> refers to the app:edited (not the atom:updated)
> value? 

Collection feeds should always be ordered by app:edited. If you want a
feed ordered in a different way, you can do so with a different feed
(perhaps linked from the service document or from the collection feed)

> And I have to ask (because I am insanely anal retentive)
> about that little thing about document order of sibling
> elements not being significant in XML. While I realize
> that there are many, many, many (most?) applications
> out there that make the document order of sibling
> elements meaningful, technically if we have two
> <entry> elements with identical app:edited values
> then the order of those entries is unspecified.
> If we wanted to order our feed along another axis I
> suppose we could add an index attribute to ensure
> intended ordering.

RFC 5005 doesn't require any within-document ordering. When consuming
RFC 5023 feeds, I recommend that you assume as little as you can about
the ordering of entries within a page and the ordering of entries across
pages. When producing AtomPub collection feeds, always produce the
documents in app:edited order. Whenever possible, give each entry a
unique app:edited value so that you don't have to worry about how to
order entries with the same timestamp. For feeds other than collection
feeds, the RFC 5005 paging mechanism gives you a lot of flexibility. 

- Brian