Eric Scheid wrote: > Could we not go this path: the core APP spec talks about discoverability > of introspection, but not detail of the format. A complementary spec for > each format can then be written detailing the format. This model also > leaves the door open for someone inventing an even better introspection > format down the road. > > Politically, WG wise, life would be nicer too. The XOXO advocates can > write a "XOXO Introspection Format For Atom" spec, the XMP advocates can > write a "XMDP Introspection Format For Atom", (and so on) ... and > there'll be no shit fight as to who gets their format into the Atom > Publishing Protocol spec.
I was about to propose the same: splitting AtomPP into several I-D, one per AtomPP module. The first one should be easy to mint as there is general consensus: AtomPP Collections and Members (defines that a collection is represented as an Atom Feed Documents that can be accessed with issuing an HTTP GET, defines creation of members as POSTing those members at the collection URI however, doesn't define entry vs. generic collections and constraints on members, leaving it for another spec, defines GET, PUT and DELETE on member URIs). Then let's explore introspection documents, collection capabilities (introduces the notion of entry vs. generic collections), etc. -- Thomas Broyer
