On Jun 10, 2009, at 11:52 AM, Martin Atkins wrote:
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.
I am glad you are speaking up about this. The original proposal for in-
lining as expressed in draft-divilly-atom-hierarchy-01 was rather
modest and supported a rather simple use case.
However, per Mark Nottingham et al [1], the use of the ae:inline is
held up as the right way of extending Atom. Plus, per James Snell [2],
the inline content's media type is better gleaned from ae:inl...@type
attribute. Also, per Al Brown et al. [3] [4] [5], it was more
important to ensure maximum flexibility than demonstrate specific 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.
I agree that the current model is super flexible, perhaps to the point
of complicating even basic behavior. However, we need some consensus
on the level of flexibility and cost we can agree to.
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.
[1] http://www.imc.org/atom-syntax/mail-archive/msg21053.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg21084.html
[3] http://www.imc.org/atom-syntax/mail-archive/msg21088.html
[4] http://www.imc.org/atom-syntax/mail-archive/msg21096.html
[5] http://www.imc.org/atom-syntax/mail-archive/msg21121.html
