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,
Unfortunately not http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.ltgt.net%2Fatom%2Fintrospection.atom It seems the FeedValidator fails detecting missing atom:author elements. Most are minor errors, but one is not trivial: "line 14, column 3: Missing content or alternate link (3 occurrences)" http://feedvalidator.org/docs/error/MissingContentOrAlternate.html Using atom:content/@src instead of atom:[EMAIL PROTECTED]"collection"]/@href first requires having an atom:summary (minor requirement, the summary might be empty) but also, more important, implies (at least from my pov) the collection accepts GET, which might not be the case (for example, POST-only collection for comments and trackbacks). Using atom:[EMAIL PROTECTED]"alternate"] (in addition to atom:[EMAIL PROTECTED]"collection"]) doesn't help, as a collection might not have an alternate (for example, collections used as part of workflows see PaceWorkflows, there might be better examples though... how about an endpoint allowing you to send a comment, ask a question, etc. similar to many "feedback appreciated" forms on the Web?) I'd however be OK to use atom:content/@src instead of atom:[EMAIL PROTECTED]"collection"]/@href, even if the collection isn't "readable" (provided that a 403 Forbidden or 401 Unauthorized be returned, not a 405 Method Not Allowed). -- Thomas Broyer
