Re: New Version Notification for draft-mehta-atom-inline-00

["Nikunj R. Mehta" <[e-mail]>]

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.

>
> 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