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
+1 at first sight > and categories are used to link related collections? -1 We're back to trying to assemble flat data into hierarchical data. Using categories is not better than using atom:link/@title. Why couldn't the categories reflect which categories you can use in your entries posted to the collection? (if a collection contains or may contain entries belonging to "Atom", "RSS" and/or "Syndication" categories, then it's not false to say the collection itself belongs to the "Atom", "RSS" and "Syndication" categories). I'd also add that implementations may accept other categories as well (opens the door for "tagging"); in other worlds, clients should consider the set of categories as an opened set. An extension element might be added to tell clients it's rather a closed set (e.g. app:accept-any-category=yes|no with defaulting to "yes") If you want a hierarchical model, you can point to another "Introspection Feed". In your example, there would be an "Introspection Feed" describing the "Main Site" and "Side Bar Blog", plus one "Introspection Feed" for each of these "blogs" describing their collections. The only thing I'm not clear about is how to distinguish an "Introspection Feed" from a "Collection Membership Feed" (how to distinguish an entry describing another "Introspection Feed" from one describing a collection). > Some basic benefits: > > - No format invention. This one is already well-specified and agreed upon > :) +1 > - Uses <atom:category> values to link related collections. -1. Using atom:link/@title in existing gregorio-09 implementations has been pointed out as a drawback; using atom:category is no different. > - 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). +1 (e.g. list-templates and member-types) > - 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) Nesting could be supported in my proposal above if an atom:entry could at the time describe a collection and link to another "Introspection Feed". -- Thomas Broyer
