Kyle Marvin wrote:
Not that we need *more* options, but when we do introspection (whether
in core or elsewhere), I'm wondering why we need to invent any new XML
format. Why can't the introspection document just (itself) be an
Atom feed, where entries describe collections and categories are used
to link related collections?
The following example seems suitable, is valid Atom, and fully
represents the model shown in the draft-06 introspection document
example (7.2):
<feed xmlns="http://www.w3.org/2005/Atom";
xmlns:app="http://purl.org/atom/app#";>
<title>My Blog Collections</title>
<id>{service id}</id>
<updated>2005-11-04T20:00:02Z</updated>
<entry>
<id>{collection id 1}</id>
<updated>2005-11-04T18:30:02Z</updated>
<title>My Blog Entries</title>
<category>Main Site</category>
<link rel="collection" href="http://example.org/reilly/main"/>
<app:member-type>entry</app:member-type>
<app:list-template>http://example.org/{index}</app:list-template>
</entry>
<entry>
<id>{collection id 2}</id>
<updated>2005-11-04T20:00:02Z</updated>
<title>Pictures</title>
<category>Main Site</category>
<link rel="collection" href="http://example.org/reilly/pic"/>
<app:member-type>media</app:member-type>
<app:list-template>http://example.org/p/{index}}</app:list-template>
</entry>
<entry>
<id>{collection id 3}</id>
<updated>2005-11-03T9:00:02Z</updated>
<title>Remaindered Links</title>
<category>Side Bar Blog</category>
<link rel="collection" href="http://example.org/reilly/list"/>
<app:member-type>media</app:member-type>
<app:list-template>http://example.org/l/{index}</app:list-template>
</entry>
</feed>
Some basic benefits:
- No format invention. This one is already well-specified and agreed upon :)
- Uses <atom:category> values to link related collections.
- The built-in extensibilty of <atom:feed> and <atom:entry> provides a
nice place to hang service-level and/or collection-level metadata.
This makes it easy to add domain-specific metadata downstream for
specific types of collections (like blogs).
- An Atom client should already have a parser for the above readily available :)
- Lots of other standard atom elements seem like they might be apropos
to include as collection metadata (author, contributors, rights, ...).
- <atom:updated> could be used on collection entries for fast sync
using only the introspection document (i.e. it is the time of the last
change to the collection).
- If someone wanted to expose a model for editting collections, that
would be pretty logical too (just use APP on the above... POST an
entry to create a collection, etc).
- Nesting _could_ be supported if desired through one of two mechanisms:
* A "collection" link that simply indirects to another introspection
document feed, or:
* use hierarchical categories. (ex. "Main Blog/Photos" from Robert's
outline pace)
(I lean towards the hierarchical categories because a) a
non-nesting-aware client could still present a view of the full set of
collections and b) all collections are returned within a single
introspection document [one GET vs. link traversal]).
- I think the spec language for the above could be pretty short and
sweet. Just define the collection link relation (a required element
in collection-describing entries), a description of any collection
metadata extension elements that reaches consensus (like media types,
list templates, or ...), and possibly updated semantics for collection
entries.
It feels to me, like minimal invention, being elegantly
self-referential, and maybe even close to the simplest thing that
could possibly work. This also seems obvious enough that either a)
someone has suggested it before and I missed it, and/or b) it is a
really dumb idea for reasons I'm missing.
I can write this up in PACE form, pending positive response and the
results of the consensus call on introspection.
This was discussed in earlier times ("Feed-Based Introspection" [1] for
one) and my impression was that it was not obviously bad. Some of the
concerns voiced at the time were (summarizing):
o As a generic feed document, the fact that it talks about other feeds
needs to be inferred from context (from the rel relationship on the link
that points to this document, for example). On the other hand, it seems
to me that using link rel="collection" in this proposal is sufficiently
disambiguative in practice.
o This feed would most likely not be one of the "sliding window" type
(most recent entry first, shows last N entries at all times...). It
fits in more with a query API and you'd certainly want to be able to use
next/prev navigation to get through a possibly large set of elements.
These things were not worked at at the time of the last set of
discussions so it was difficult to see how to do introspection without
extensions.
See also [2] for a slightly different type of feed discovery discussion.
I'd certainly like to see a Pace to compare against alternatives.
-John
[1] http://imc.org/atom-syntax/mail-archive/msg06408.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg06352.html
