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:inline@type
attribute. Also, per Al Brown et al. [3] [4] [5], it was more
important to ensure maximum flexibility than demonstrate specific use
cases.