RE: Reviving the features draft?

["Brian Smith" <brian@xxxxxxxxxxxxxx>]

Jan Algermissen wrote:
> is there any desire to update the features draft[1] (expires 
> April 29,  
> 2008)?
> 
> IMHO, it is an essential aspect of using APP in larger contexts to  
> enable services to tell clients that collections implement a certain  
> behavior. The features draft (in my view) enables late binding of  
> client to server at runtime based on server type which gives us any  
> registry functionality one would ever want.

The latest draft of the features mechanism wasn't useful, and many
people argued that previous drafts were actually harmful. Unsurprisingly
then, it hasn't been widely adopted even though it has been around
forever. It would be better to just let it expire. Below, I have copied
the most recent thread regarding the features draft (two messages, one
quoted inside the other), which explains why it isn't necessary.
Basically, it evolved into an unnecessary reinvention of XML namespaces.


If extension elements (as suggested below) are insufficient for your
application, why not use WS-Policy? It has the "WS-" mark of the beast,
but it is simple and self-contained; it should be easy to implement in
conjunction with AtomPub without bringing in all the other WS-* stuff.

Regards,
Brian

On Sun, 6 Jan 2008, 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