James M Snell wrote: > The current Atompub Features draft is located at > > http://tools.ietf.org/html/draft-snell-atompub-feature-12 > > A number of significant changes were made reflecting the > extensive discussions made on the atompub protocol list; > however, thus far, I have received very little feedback on > those changes. I would very much like to see this move > forward and would greatly appreciate it if folks could take a > look and let me know what they think.
Once you moved the "must-understand" mechanisms from this feature, this specification became unnecessary, because an application no longer has to differentiate "features" from any other extension elements. Consider: <f:features xmlns='http://purl.org/atompub/features/1.0'> <f:feature ref="http://purl.org/atompub/features/1.0/supportsDraft"; /> </f:features> vs: <supportsDraft xmlns='http://purl.org/atompub/features/1.0'/> Usually, the namespace declarations are going to be on a higher-level element: <f:features> <f:feature ref="http://purl.org/atompub/features/1.0/supportsDraft"; /> </f:features> vs: <supportsDraft/> The motivation for feature documents was the verbosity of feature descriptions. Using plain old extension elements reduces the verbosity considerably, to the point where feature documents aren't going to be much of a benefit, most of the time. The documentation aspects (f:feature/@href and f:feature/@label), are not useful enough to warrant a whole specification for this. The need for a user-readable label went away with the "must-understand" parts of the specification, because the client no longer has to be able to present the user with a list of features that it doesn't support. You said that @href is intended for programmers, not end users. Programmers should be able to find the documentation for any feature via Google easily, so it seems to not be much of a benefit. - Brian
