As we (and others) have been implementing APP, it has become clear that there needs to be some mechanism for describing the features and controls supported by an implementation. To start to address this need, I've started working on an introspection doc extension that adds three elements to the introspection doc.
Because of the current publishing freeze for new I-D's and because I'm still making tweaks here and there on the initial draft, I have not yet sent this off to the Internet-Draft publishers but I did want to make it available for folks in the WG to consider and offer feedback. [NOT YET PUBLISHED!] http://www.snellspace.com/public/draft-snell-atompub-feature-00.txt (as this is still just a first draft, consider everything to be flexible and changeable) For example, <service> <workspace title="My Blog"> <collection title="My entries" href="..."> ... <f:feature ref="http://example.org/features/foo"; required="yes" /> <f:feature ref="http://example.org/features/bar"; required="no"> <x:bar xmlns:x="...">feature specific metadata element</x:bar> </f:feature> <f:control ref="http://example.org/controls/foo"; required="no" /> <f:control ref="http://example.org/controls/bar"; required="yes"> <x:bar xmlns:x="...">control specific metadata element</x:bar> </f:control> <f:simple-control name="foo" namespace="http://example.org/controls/foo"; required="no" default="foo" fixed="yes"> <f:value>foo</f:value> <f:value>bar</f:value> </f:simple-control> </collection> </workspace> </service> In this example, the collection supports two features, one required and one optional. Clients would need to support the required feature in order to use the collection. The f:feature element can contain arbitrary feature-specific metadata. Entries in the collection use three pub:controls, two of which are specified by unique id (the client would have to be familiar with the control identifier in order to use that control) and one that is defined as a "simple control" (an element with text). One of the nice things about this approach is that questions about whether or not a given feature is supported, or whether or not there are any required features, can be determined using simple XPath statements. //f:[EMAIL PROTECTED]'http://example.org/features/foo'] //f:[EMAIL PROTECTED]'yes'] Anyway, as always, feedback/praise/gripes/suggestions are welcomed. - James
