Nikunj R. Mehta wrote:
Based on feedback, I have split out the in-lining spec in to its own I-D.
HTML: http://tools.ietf.org/html/draft-mehta-atom-inline-00
Text: http://tools.ietf.org/id/draft-mehta-atom-inline-00.txt
I
am also tracking open issues about this I-D publicly at http://code.google.com/p/atom-ext/issues/list.
The source for this I-D is also available, if you are interested.
Looking forward to comments on the I-D.
Is it actually necessary to support inlining of resources other than
atom feeds and entries? It seems like this adds considerable complexity
where I'm not sure that there are compelling use-cases.
Given how little success there has been with the complex content model
of the atom:content element in practice, it'd be my preference to avoid
over-thinking this and address only the specific use-case of referencing
other items that are themselves expressed as Atom.
In particular, I'm unsure as to what the meaning would be of the following:
<link rel="related" type="application/atom+xml" href="...">
<ah:inline type="text">Blah blah blah</ah:inline>
</link>
Is the text inside considered to be an alternate representation of this
resource? Should the content actually be the entity-encoded XML? Is this
invalid? The current draft seems to have no comment on the matter.
Restricting the problem to only inline feeds and entries also
theoretically allows the ah:inline element to be removed and the
atom:feed or atom:entry element given as a direct child of atom:link,
with the name of the element telling the processor whether it's a feed
or entry without the redundancy inherent in the ah:inline type attribute.
