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. --- Kyle
