Subject: Re: atom:category excludes atom:* children?

From: Nikunj Mehta <[email-masked]>
Date: Tue, 26 May 2009 14:30:32 -0700

I want to revive this thread as a recent IETF submission to support 
hierarchy in Atom feeds and entries [1] defines the meaning of 
atom:entry and atom:feed nested directly under atom:link elements.

Nikunj

[1] Text: 
http://www.ietf.org/internet-drafts/draft-divilly-atom-hierarchy-00.txt
HTML: 
http://www.oracle.com/technology/tech/feeds/spec/draft-divilly-atom-hierarchy.html 

Sam Ruby wrote:
>
> Bill de hOra wrote:
>>
>> No, because I see the spirit of the RFC as allowing what it does not 
>> explicitly disallow. Hence the RNC is non-normative.
>
> [snip]
>
>> I would say "huge gaping hole in the spec" were it not for my opinion 
>> that the WG worked on a default allow basis and the intent was never 
>> to restrict this kind of usage.
>
> Drats.  This thread has seemed to died down.  I had hopes...
>
> As you say, the RNC is non-normative.  And consumers of Atom need to 
> be aware that it is quite possible for subsequent RFCs to define new 
> Atom vocabulary that is to be used as immediate children of atom:feed 
> or atom:entry, let alone places which are intentional extension points.
>
> Now, as to the feed validator, this is one of those rare times that it 
> is at cross-purposes with the spec.  For the feed validator to be 
> useful, it needs to be implemented with a "default disallow" policy 
> lest it accept both atom:category and atom:catagory.
>
> If there is any actual use of atom:link inside of atom:category, I'll 
> downgrade this to a warning ("might be rejected by code that 
> overzealously uses the provided RNC as a filter").  If there is any 
> actual spec for how it is to be used, I'll eliminate the message 
> completely for the use cases provided by the spec.
>
> - Sam Ruby
>
>