Interesting thread. I would take this to support allowing atom:entry's inside
an atom:entry.
That seems (to me) a natural way in xml to express a tree/hierarchy.
Best, Al
Sent from BlackBerry.
----- Original Message -----
From: Nikunj Mehta [[email protected]]
Sent: 05/26/2009 02:30 PM MST
To: Sam Ruby <[email protected]>
Cc: Bill de hOra <[email protected]>; atom-syntax Syntax <[email protected]>
Subject: Re: atom:category excludes atom:* children?
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
