Subject: Fwd: New Version Notification for draft-mehta-atom-inline-00

From: "Nikunj R. Mehta" <[email-masked]>
Date: Wed, 10 Jun 2009 09:55:37 -0700

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.

Nikunj
http://o-micron.blogspot.com

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: June 9, 2009 4:37:44 PM PDT
> To: [email-masked]
> Subject: New Version Notification for draft-mehta-atom-inline-00
>
>
> A new version of I-D, draft-mehta-atom-inline-00.txt has been  
> successfuly submitted by Nikunj Mehta and posted to the IETF  
> repository.
>
> Filename:	 draft-mehta-atom-inline
> Revision:	 00
> Title:		 In-lining Extensions for Atom
> Creation_date:	 2009-06-09
> WG ID:		 Independent Submission
> Number_of_pages: 9
>
> Abstract:
> This specification defines mechanisms for in-lining representations
> of linked resources in Atom documents.Editorial Note
>
> To provide feedback on this Internet-Draft, join the atom-syntax
> mailing list (http://www.imc.org/atom-syntax/) [1].
>
>
>
> The IETF Secretariat.
>
>

---

From: Martin Atkins <[email-masked]>
Date: Wed, 10 Jun 2009 11:52:15 -0700

Nikunj R. Mehta wrote:
> Based on feedback, I have split out the in-lining spec in to its own I-D. 
> 
> 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.
> 

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.

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Wed, 10 Jun 2009 12:45:52 -0700

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

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

---

From: James M Snell <[email-masked]>
Date: Wed, 10 Jun 2009 13:11:43 -0700

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
>>> 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.
> 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 
To be clear, what I was suggesting was that if you were going to be 
pointing to the atom:content rules as the model for processing ae:inline 
then it would better for ae:inline to have its own type attribute 
distinct from the atom:link elements type attribute.  How to handle 
things if there is a mismatch between the atom:link/@type and the 
ae:inline/@type (or the atom:link/@type and the actual content type of 
the linked resource after performing an HTTP GET) is a separate issue 
altogether.

Further, it is possible to define the "up" and "down" links generically, 
but to define -- separately -- some set of rules that limit their use to 
construct an Atom-only hierarchy.  In a theoretical Atom-only hierarchy, 
"up" and "down" links that point to anything other than Atom documents 
would simply be ignored by a processor. Defining that Atom-only 
hierarchy, however, should not restrict the use of those link relations 
to build other kinds of hierarchies.

- James

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Wed, 10 Jun 2009 13:14:49 -0700

Nikunj

On Jun 10, 2009, at 1:11 PM, James M Snell wrote:

>>> Is it actually necessary to support inlining of resources other  
>>> than atom feeds and entries? It seems like this adds considerable  
>> in-lining as expressed in draft-divilly-atom-hierarchy-01 was  
>> rather modest and supported a rather simple use case.
>>
>> 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.
>>
> pointing to the atom:content rules as the model for processing  
> ae:inline then it would better for ae:inline to have its own type  
> attribute distinct from the atom:link elements type attribute.  How  
> to handle things if there is a mismatch between the atom:link/@type  
> and the ae:inline/@type (or the atom:link/@type and the actual  
> content type of the linked resource after performing an HTTP GET) is  
> a separate issue altogether.

Do you find the current I-D text satisfactory or do you agree it is  
more complex than it needs to be?

>
> Further, it is possible to define the "up" and "down" links  
> generically, but to define -- separately -- some set of rules that  
> limit their use to construct an Atom-only hierarchy.  In a  
> theoretical Atom-only hierarchy, "up" and "down" links that point to  
> anything other than Atom documents would simply be ignored by a  
> processor. Defining that Atom-only hierarchy, however, should not  
> restrict the use of those link relations to build other kinds of  
> hierarchies.

I don't think in-lining is restricted to only "up" and "down" anymore.

---

From: James M Snell <[email-masked]>
Date: Wed, 10 Jun 2009 13:22:41 -0700

Nikunj R. Mehta wrote:
> <snip>
For the "up" and "down" links yes, I think it's much better. As for 
ae:inline, I like that it has been separated out into a separate I-D but 
I am still definitely on the fence about whether in-lining is even 
something that should be done. I've never liked the idea of making the 
Atom syntax hierarchical and I haven't seen anything yet that has 
convinced me otherwise.

- James

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Wed, 10 Jun 2009 13:24:17 -0700

Nikunj

On Jun 10, 2009, at 1:22 PM, James M Snell wrote:

>
>
> Nikunj R. Mehta wrote:
>> <snip>
>>>>
>>>> I am glad you are speaking up about this. The original proposal  
>>>> for in-lining as expressed in draft-divilly-atom-hierarchy-01 was  
>>>> 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.
>>>>
>>> To be clear, what I was suggesting was that if you were going to  
>>> be pointing to the atom:content rules as the model for processing  
>>> attribute distinct from the atom:link elements type attribute.   
>>> How to handle things if there is a mismatch between the atom:link/ 
>>> @type and the ae:inline/@type (or the atom:link/@type and the  
>>> actual content type of the linked resource after performing an  
>>> HTTP GET) is a separate issue altogether.
>>
> For the "up" and "down" links yes, I think it's much better.

"up" and "down" links are not defined in atom-inline. This thread is  
actually seeking feedback on atom-inline only. That leads me to think  
that you are in favor of the current complexity in the in-line content  
model.

> As for ae:inline, I like that it has been separated out into a  
> separate I-D but I am still definitely on the fence about whether in- 
> lining is even something that should be done. I've never liked the  
> idea of making the Atom syntax hierarchical and I haven't seen  
> anything yet that has convinced me otherwise.
>

This is an experimental I-D that seeks to formalize and harmonize what  
has already been offered commercially. It would be useful to know  
about your concerns so that we can experimentally validate them.