Re: [rest-discuss] Re: Deigning representations of collections and references
- Have you looked at the threading extensions for Atom?
I'm not a big fan of the service document. As far as generic clients
go, I think they can infer the editability of a resource by the
presence of a link rel='edit' without needing to consult a service
document. The response to a PUT request is what's authoritative, not
any sort of service document. Allow headers work just as well to
provide a hint as to acceptable methods.
Where I do use a "service document" in an otherwise-Atom Protocol
system, I repurpose Google's XML sitemaps so I have a hierarchical
format, instead of using a root-level flat-file document to define a
You can also have feeds of feeds in Atom, so I don't really understand
the disadvantage you're seeing. I didn't propose Atom as the magical
solution to your problem, merely as a way forward. Once you've
identified its actual shortcomings, you're free to abandon it, but it
will give you an awful lot of ideas on how to use link relations
properly. See it through, though, since it provides a useful guideline
on how to arrange and link collections.
You can use standard link relations, even if you use your own
vocabulary as a resource model. Better to use standard media types,
> Mike, thank you for pointing out the draft inlining spec... it was
> Jan, I started off the thread suggesting a format similar to the one
> that you put forward as one of my alternatives. I have been convinced
> by the idea that really the collection should not contain Account
> elements but some sort of link. The inlining idea is good in that it
> formalises combining a link with some data from the target
> resource.... at least it would be if the spec had moved forward from
> being a draft ;-)
> However, what I'm really pushing for is an example of publishing a
> feed (or even feeds) within other content, for example within the
> seller element from my last post. If I end up with something similar
> to my last post (i.e. a seller element that contains a feed element)
> I'm back to a custom vocabulary... at which point I can't see the
> advantage of using Atom feeds... a generic client would never find
> the feeds in the first place (because my seller element doesn't look
> anything like a Service document)... Any thoughts?
- Thanks for the quick response Eric. I'm certainly not dismissing Atom yet and I hope I'm learning a lot from it and this discussion.
You mention a feed of feed approach... would that be a <feed> element that represents the parent resource, which then contained an <entry> for each "collection"? With the <entry> containing a link to the feed for that child collection (and possibly also containing an <inline> to provide a high level view of the child feed's content)?
I think what I'm missing is some good examples of using Atom outside of the basic scenario. So given a resource that has properties of its own, and perhaps is linked to at least one possibly two collections of other resources... how would you represent it? What XML would you envisage being returned when the parent is requested?
Thanks everyone for your time!
- "piers_lawson" wrote:
>Yes. If the client wants to access a feed within a feed, it can follow
> You mention a feed of feed approach... would that be a <feed> element
> that represents the parent resource, which then contained an <entry>
> for each "collection"? With the <entry> containing a link to the feed
> for that child collection (and possibly also containing an <inline>
> to provide a high level view of the child feed's content)?
the link rel='related' instead of the link rel='self' of an entry in
the original feed. The link rel='self' just points to the first entry
in the sub-collection.
This is the first I've heard of <inline>, so I can't answer as to that.
- Thanks Eric,
Could you post a small sample showing what you mean exactly. So a feed that contains one (or even better two feeds)... and for the parent feed and the child feeds they contain some additional data beyond the standard fields supportted by Atom. I think an example would really solidify it in my mind.
Thank you for your input so far!
- "piers_lawson" wrote:
>I'm working on your example. The demo I posted shows what I'm talking
> Could you post a small sample showing what you mean exactly. So a
> feed that contains one (or even better two feeds)... and for the
> parent feed and the child feeds they contain some additional data
> beyond the standard fields supportted by Atom. I think an example
> would really solidify it in my mind.
about, but I haven't worked the rest of my solution into the demo yet.
When I have, I'll bump here. I'm almost finished (I think) making the
XSLT also function in Opera (using a holistic approach to the cross-
browser XSLT problem, rather than using @mode and an engine test, i.e.
making some code specific to Mozilla's Transformiix processor or Opera's
After I've made the XSLT work with WebKit, I'll work those other tricks
up my sleeve for dealing with collections into the demo. Then I'll make
the XSLT work with IE, so I can get back to my original problem, which
is dealing with Xforms. IE has a couple of nice Xforms extensions
The result of this work, for me, will be a development style based on
the union of subsets of XSLT 1.0, EXSLT and Xforms that works on the
Web. And, a coding style (which can be validated using RELAX NG +
Schematron) for hitting that cross-browser sweet spot, which results in
code that also works for server-side transformation (if nothing else
works, libxslt can be used on the server).
Anyway, I ought to be able to provide an interesting collection example
for you later this week.