Re: Reviving the features draft?

["Eric Larson" <ionrock@xxxxxxxxx>]

Hi,

On Mon, Apr 21, 2008 at 9:33 AM, James M Snell <jasnell@xxxxxxxxx> wrote:
>
>  f:feature is a "regular extension element" that addresses one very specific
> problem: enumerating all of the specified features without having to first
> understand those features.
>
>  For example, given:
>
>   <collection href="...">
>    <a:title>foo</a:title>
>    <accept>...</accept>
>    <a:b />
>    <c:d />
>    <e:f />
>   </collection>
>
>  If I am not familiar with a:b, c:d, or e:f, I have no idea if they
> represent features or some other extension element used for some other
> purpose.
>
>  However, given:
>
>   <collection href="...">
>    <a:title>foo</a:title>
>    <accept>...</accept>
>    <f:feature ref="http://.../a"; />
>    <f:feature ref="http://.../b"; />
>    <e:f />
>   </collection>
>
>  I know exactly what the two f:feature elements indicates without having to
> know exactly what feature the ref is identifying.  This allows me to me
> explicitly whether there are any features supported by the collection that I
> do not support, which is an important use case. This is not possible using
> the other approach.
>
>  - James
>

One aspect that seems important in implementing a feature is whether
or not server will remove unknown features/extensions. As a client, I
understand that it is not trivial to programmatically find whether or
not a feature is supported, but at the very least knowing that an
unknown element will not be removed could be "supported" enough. After
all, if the elements show up in feeds it doesn't really matter whether
or not the server recognized or made an effort to do something with
it.

I might be missing something here, but it sounds like making a
distinction between features that the server not only allows in terms
of unknown and/or extensions, but actively operates on should be
considered. A great example of this is the threading extension.
Technically any feed that doesn't remove the thr:in-reply-to could be
considered "supporting" the extension even though nothing actually
happens from the client perspective. For example, if the server can be
queried based on the thr:in-reply-to, then has already potentially
added functionality beyond the protocol.

Sorry if I'm confusing the issue, but I consistently get confused when
this is brought up as to what is truly being solved on the protocol
level, compared to what is being addressed in the implementations.

Eric Larson

>
>
>  Brian Smith wrote:
>
> > Eric Scheid wrote:
> >
> > > On 21/4/08 10:38 AM, "Brian Smith" <brian@xxxxxxxxxxxxxx> wrote:
> > > So then, is using atom:link to describe capabilities/features/etc rather
> than describing
> > > links to related resources one more example of that?
> > >
> >
> > If atom:link doesn't make sense, you can use a regular extension
> > element.
> >
> > - Brian
> >
> >
> >
>
>