RE: Reviving the features draft?

["Brian Smith" <brian@xxxxxxxxxxxxxx>]

James M Snell wrote:
> I doubt using the atom:link element would be appropriate 
> because it is very counter intuitive to the use case --
> that is, we're trying to describe
> capabilities/features/etc rather than describing links
> to other resources. I guess it could be made to work but
> it just smells bad.

There are a couple of advantages to using atom:link:

(1) Documents can use the link relations to link directly to collections
that have a particular feature that they care about (using <a
rel="XXX">), instead of linking to a service document which describes a
set of collections that may or may not have that feature.

(2) Service documents can link to another resource that provides the
feature on behalf of the collection. For example, a collection could
provide an alternative resource that is FeedSync enabled, a different
resource that should be used for posting drafts (especially drafts of
media resources), and/or a different resource that is compatible with
GData's query language.

> Using extension elements could also work but it increases the parsing 
> and processing complexity a bit.
>
> Sorry, not convinced yet.

If something can be done using existing standards, we should avoid
creating new ways of doing things, unless the new ways are clearly
superior to the existing mechanisms. In other words, I before proposing
something new, we should first demonstrate that there are not acceptable
existing solutions, and then build small extensions on top of existing
standards. I'm not trying to argue *against* new ideas as much as I am
trying to argue *for* the reuse of existing standards. Here, there are
so many existing solutions that there hardly seems room for new ones.

Regards,
Brian