Re: Reviving the features draft?

["'Aristotle Pagaltzis'" <pagaltzis@xxxxxx>]

* Brian Smith <brian@xxxxxxxxxxxxxx> [2008-05-01 07:50]:
> 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.

There is nothing preventing you from putting links in the service
document next to the feature support declaration element.

> 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. 

There is nothing preventing you from putting extension elements
pertaining to that feature in the service document outside of the
atom:category that declares support for the respective feature.

> 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.

If some features are enumerated that way but not all of them
that’s still more helpful than if no features are enumerated at
all. So the “everybody” qualification is mistaken. But once you
lose that qualification, all you are left saying is that
extension elements will never work unless people support them,
which is tautological.

> That is unlikely because there isn't any incentive for
> extension creators to do so

Anyone can define category terms for anyone else’s features. If
consensus forms among people using those terms, they needn’t be
blessed by the extension creator at all for the consenting people
to benefit from the use of those terms. This is the same thing
people misguidedly say about RDF: “people will never agree on a
universal ontology.” Well yeah, the whole point is that they can
make their own local agreements and derive value from those
without needing universal buy-in.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>