RE: Reviving the features draft?

["Brian Smith" <brian@xxxxxxxxxxxxxx>]

Aristotle Pagaltzis wrote:
> * Bill de hOra <bill@xxxxxxxxxx> [2008-04-27 20:25]:
> > Brian Smith wrote:
> >>   <app:collection href='http://example.org/collection'>
> >>       <link rel='http://example.org/orderProcessor'
> >>             href='http://example.org/collection'/>   
> >>    </app:collection>
> >
> > Link is the wrong markup for this. Use atom:category to
> > categorize resources. If you need something more formal, then
> > use RDF.
> 
> With the caveat, therefore, that we need to be aware that putting
> atom:category directly inside app:collection is an extension of
> RFC 5023, I would agree that this is the right approach.

There are likely cases where linking doesn't make sense; however, I have found several cases where it made sense for a collection to support a feature (optionally) at a URI distinct from the collection URI. FeedSync is a great example; I want to support FeedSync in my AtomPub collections but I don't want the FeedSync stuff to be in the main collection feed. Similarly, I would like to support the GData search syntax, but I'd like to support it at a different URI from the collection URI. In those situations, flags that say "I support GData queries" or "I support FeedSync" are not nearly as helpful as link relations.

Further, I think using atom:category is the wrong approach. It is useful to put feature declarations into feeds (and maybe entries), and some features need to have additional information that we'd have to embed within the atom:category element. Although I agree that embedding markup within atom:category elements is perfectly fine according to the spec., others (maybe James?) have claimed that we should avoid doing so since many applications do not handle that well. 

> * James M Snell <jasnell@xxxxxxxxx> [2008-04-21 16:40]:
> >  <collection href="...">
> >    <a:title>foo</a:title>
> >    <accept>...</accept>
> >    <f:feature ref="http://.../a"; />
> >    <f:feature ref="http://.../b"; />
> >    <e:f />
> >  </collection>
> >

> I would cast this as
> 
>  <collection href="...">
>    <a:title>foo</a:title>
>    <accept>...</accept>
>    <a:category scheme="http://example.org/feature"; 
>                term="http://.../a"; />
>    <a:category scheme="http://example.org/feature"; 
>                term="http://.../b"; />
>    <e:f />
>  </collection>
> 
> Then you can look for categories of collections in a certain
> scheme if you want to enumerate the features of a collection, but
> you can also express different classes of collection properties
> by associating each class with a scheme. This seems like it
> should cover uses of Atompub in non-publishing context; an issue
> that also came up recently.

Attempting to parse atom:category or f:feature elements to enumerate all the features of a collection will never work unless everybody agrees to mark up their features with this extra markup. That is unlikely because there isn't any incentive for extension creators to do so; after all, what exactly is the use case for enumerating all the features of a collection? It is something that somebody might want to do sometime, maybe?

Regards,
Brian