Subject: Re: New Version Notification for draft-mehta-atom-inline-01

From: Mark Nottingham <[email-masked]>
Date: Mon, 13 Jul 2009 13:21:34 +1000

Some (belated) feedback:

* The new syntax is too verbose; to inline something, you're forced to  
surround it in two elements, <ae:inline> and then either <feed> or  
<entry>.  I'd suggest one of the following two remedies:
   a) use one element with a "type" attribute: <ae:inline  
type="feed">...</ae:inline> or
   b) define multiple elements, one of which may be used as a child of  
atom:link: <ae:feed> or <ae:entry>
I have a slight preference for (b).

* As noted earlier on the list, there's some level of confusion/ 
disagreement about whether parameters are allowed on atom:link/@type;  
it's probably safest not to use these, but instead to rely on the  
element used to disambiguate this.

* There's potential for duplicated information between the link  
relation and the inlined content, especially in @title and @href. Have  
you considered giving advice on when and where it should be omitted?

E.g., if @title is present, you could say that it's not necessary to  
serialise ae:inline/feed/title. This means that the XML contained in  
the feed element isn't a valid Atom feed if it's cut-and-pasted, but  
then again it probably isn't anyway (thanks to the glories of XML) and  
if this is handled well, it will make inlining more useable for cases  
where there isn't a lot of content.

* Does atom:author, xml:lang, etc. inherit from the inlined content's  
context?

* I know it's been discussed and changed in the most recent draft, but  
I actually *do* have use cases where inlining non-Atom content would  
be useful; e.g., images. By constraining this mechanism to only work  
with feeds and entries, it will (of course) only work with links *to*  
feeds and entries, and this is quite limiting; potentially, it's  
useful to inline *any* kind of link.

However, since some feel that supporting the atom:content model makes  
it too complex, (b) above may actually be more attractive; by having a  
separate, third optional <ae:content> element, people can choose  
whether that's supported or not.

Cheers,

On 30/06/2009, at 7:12 AM, Nikunj R. Mehta wrote:

> Revised version simplifies the content model of ae:inline to Atom  
> entry and feed documents.
>
>    01 - Limited scope of in-lining to Atom.
>       Removed type attribute from ae:inline as well as support for  
> non-Atom in-lining.
>       Specified the interpretation of type attribute and the value  
> of ae:inline
>       Added example for empty inline element
>
> I hope this addresses the concern that we were creating a mighty  
> complex content model for ae:inline without use cases to guide us in  
> the process. At this point, I welcome any feedback of implementation  
> experience you wish to share.
>
> Thanks to all of you who provided feedback on the initial revision  
> of the I-D.
>
> Nikunj
> http://o-micron.blogspot.com
>
> Begin forwarded message:
>
>> From: IETF I-D Submission Tool <[email-masked]>
>> Date: June 29, 2009 2:08:41 PM PDT
>> To: [email-masked]
>> Subject: New Version Notification for draft-mehta-atom-inline-01
>>
>>
>> A new version of I-D, draft-mehta-atom-inline-01.txt has been  
>> successfuly submitted by Nikunj Mehta and posted to the IETF  
>> repository.
>>
>> Filename:	 draft-mehta-atom-inline
>> Revision:	 01
>> Title:		 In-lining Extensions for Atom
>> Creation_date:	 2009-06-29
>> WG ID:		 Independent Submission
>> Number_of_pages: 8
>>
>> Abstract:
>> This specification defines mechanisms for in-lining representations
>> of linked Atom resources.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.
>>
>>
>

--
Mark Nottingham     http://www.mnot.net/

---

From: <[email-masked]>
Date: Mon, 13 Jul 2009 01:42:54 -0400

Hi Mark,

True, the following is more verbose...

<atom:link rel="something" href="...">
  <ae:inline>
    <atom:feed>
      ...
    </atom:feed>
  </ae:inline>
</atom:link>

than either of the alternatives you suggest, yet it strikes me that then
being able to inline an atom feed, rather than something that is not an
atom feed (even if it looks an awful lot like an atom feed) is a good
trade for that verbosity?

Cornelia

Cornelia Davis
Senior Technologist
EMC Corporation, Office of the CTO
[email-masked]
p: 805.560.9039
m: 805.452.8941
f: 805.880.0390

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 13 Jul 2009 15:53:40 +1000

But it isn't, You can never just dump the bits in; you have to be  
careful about things like namespace declarations, entity declarations,  
xml:lang, xml:base, and atom-specific things that may or may not be  
inherited.

For better or worse, people do react negatively to extra layers of  
elements like this.

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Mon, 13 Jul 2009 16:09:18 -0700

Hi Mark,

Thanks for the close look at the in-line I-D. I am tracking three  
issues from your feedback:

Implications of in-lining inside Atom documents [1]
Syntax too verbose [2]
Support in-lining of non-Atom content [3]

The verbosity question has alternately been asked as:

1. Why invent a new container when atom:feed and atom:entry could be  
potentially in-lined without violating Atom
2. Why make the design as complicated as that of atom:content?

The approach in inline-01 is a compromise between all three concerns.  
The two approaches, (a) and (b), you suggest below:

1. end up forking the meaning of "feed" and "entry" and future specs  
would have to specify applicability of their mechanisms in the context  
of the new mechanism in addition to their use in RFC4287. A lot of the  
meta data specialized for feeds such as link relations (paging),  
identity, and others would have to be repeated in the new element.

2. cause confusion and human errors because of mis-understood  
namespaces. I see the following usage quite likely, even though it is  
inadvertent:

<atom:link rel="down" href="...">
   <atom:feed>
     ...
   </atom:feed>
</atom:link>

even though this I-D would have defined the meaning of feed in a  
different namespace. So option (b) taken literally would not be  
appropriate. As a result, your conclusion probably justifies the  
position taken in (1) above.

I do think, though, that your intention is to support a mechanism for  
summarizing the content of the referenced resource in as light-weight  
an in-lined manner as possible. Perhaps we can combine it with the use  
case of in-lining an Atom document. I am not sure, though, if these  
use cases are one and the same.

As for the duplication of metadata and content [4], I will go through  
and provide explanations for each of the cases identified in [1]. I  
agree that this is an important issue and we need to carefully tread  
this space. The approach should make it easy to in-line content if all  
the content is being homogeneously managed. In other words, it should  
be possible to copy bits directly if one doesn't allow untrusted DTD  
entities, serializes everything to UTF-8, starts every Atom document  
with its own xml:lang and xml:base (and bi-di) metadata, and so on.

The use case for non-Atom content to be in-lined definitely ought to  
be given thought. Would a separate mark-up mechanism be best for  
addressing this, as opposed to using ae:inline? I am not so sure. In  
any case, I am striving to at least be methodical about giving up on  
the design approach taken by RFC4287 in how it deals with arbitrary  
content and in-lining (an entry document in a feed document).

Regards,
Nikunj

[1] http://code.google.com/p/atom-ext/issues/detail?id=6
[2] http://code.google.com/p/atom-ext/issues/detail?id=7
[3] http://code.google.com/p/atom-ext/issues/detail?id=8
[4] http://o-micron.blogspot.com/2009/07/embed-xml-document-inside-another-xml.html

On Jul 12, 2009, at 8:21 PM, Mark Nottingham wrote:

> Some (belated) feedback:
>
> * The new syntax is too verbose; to inline something, you're forced  
> to surround it in two elements, <ae:inline> and then either <feed>  
> or <entry>.  I'd suggest one of the following two remedies:
> disagreement about whether parameters are allowed on atom:link/ 
> @type; it's probably safest not to use these, but instead to rely on  
> the element used to disambiguate this.
>
> relation and the inlined content, especially in @title and @href.  
> Have you considered giving advice on when and where it should be  
> omitted?
>
> then again it probably isn't anyway (thanks to the glories of XML)  
> and if this is handled well, it will make inlining more useable for  
> cases where there isn't a lot of content.
>
> * Does atom:author, xml:lang, etc. inherit from the inlined  
> content's context?
>
> * I know it's been discussed and changed in the most recent draft,  
> but I actually *do* have use cases where inlining non-Atom content  
> would be useful; e.g., images. By constraining this mechanism to  
> only work with feeds and entries, it will (of course) only work with  
> links *to* feeds and entries, and this is quite limiting;  
> potentially, it's useful to inline *any* kind of link.
>
> However, since some feel that supporting the atom:content model  
> makes it too complex, (b) above may actually be more attractive; by  
> having a separate, third optional <ae:content> element, people can  
> choose whether that's supported or not.
>
> Cheers,
>
>
>> complex content model for ae:inline without use cases to guide us  
>> in the process. At this point, I welcome any feedback of  
>> implementation experience you wish to share.
>>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 15 Jul 2009 15:44:21 +1000

On 14/07/2009, at 9:09 AM, Nikunj R. Mehta wrote:
> would have to specify applicability of their mechanisms in the  
> context of the new mechanism in addition to their use in RFC4287. A  
> lot of the meta data specialized for feeds such as link relations  
> (paging), identity, and others would have to be repeated in the new  
> element.

When you say "repeated", are you referring to repeating the  
specification of these things, or repeating the content itself in the  
feed?

Assuming that it's the former, this is a concern, although I'd  
personally be inclined to try. Of course, if this were a standards- 
track extension, we could use the form below (i.e. embedding atom:feed  
and atom:document directly as a child of atom:link).

> namespaces. I see the following usage quite likely, even though it  
> is inadvertent:
>

No; this is what the feed validator is for. People will make mistakes  
-- especially with XML -- no matter what we do.

> As for the duplication of metadata and content [4], I will go  
> through and provide explanations for each of the cases identified in  
> [1]. I agree that this is an important issue and we need to  
> carefully tread this space. The approach should make it easy to in- 
> line content if all the content is being homogeneously managed. In  
> other words, it should be possible to copy bits directly if one  
> doesn't allow untrusted DTD entities, serializes everything to  
> UTF-8, starts every Atom document with its own xml:lang and xml:base  
> (and bi-di) metadata, and so on.

That's very restrictive, and IMO don't belong in the spec itself.

> content and in-lining (an entry document in a feed document).

I think it largely depends on how the discussion above goes, but I'd  
hope that the draft (never mind the specific element used) would cover  
this.

Cheers,

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Wed, 15 Jul 2009 21:20:34 -0700

On Jul 14, 2009, at 10:44 PM, Mark Nottingham wrote:

>> 1. end up forking the meaning of "feed" and "entry" and future  
>> specs would have to specify applicability of their mechanisms in  
>> the context of the new mechanism in addition to their use in  
>> RFC4287. A lot of the meta data specialized for feeds such as link  
>> relations (paging), identity, and others would have to be repeated  
>> in the new element.
>
> specification of these things, or repeating the content itself in  
> the feed?

I meant repeating the specification. If atom:feed and ae:feed walk the  
same way and talk the same way, then why bother creating different  
things?

> track extension, we could use the form below (i.e. embedding  
> atom:feed and atom:document directly as a child of atom:link).

Good to hear that. I would argue that we should work towards the goal  
of eliminating ae:inline so that atom:feed and atom:entry can be  
directly embedded. What is the best way to get there?

1. An experimental track RFC (in 2009) that uses ae:inline followed by  
a standards track RFC that legalizes using atom:feed/atom:entry  
directly under atom:link (in 2010/11)

2. An An experimental track RFC (in 2009) that legalizes using  
atom:feed/atom:entry directly under atom:link (in 2010/11) and  
standardizing this later (in 2010/11)

3. A standards track that legalizes using atom:feed/atom:entry  
directly under atom:link (in 2010/11)

> No; this is what the feed validator is for. People will make  
> mistakes -- especially with XML -- no matter what we do.
>

Let's not make it any more likely for people to make mistakes. This  
issue will be moot if we go on approach 2 or 3.

>> through and provide explanations for each of the cases identified  
>> in [1]. I agree that this is an important issue and we need to  
>> UTF-8, starts every Atom document with its own xml:lang and  
>> xml:base (and bi-di) metadata, and so on.
>

My point is simply that the "embedding case" should be trivial, just  
like embedding text in atom:content is trivial. Other cases must be  
supported, albeit with appropriate metadata.

>
>
>> The use case for non-Atom content to be in-lined definitely ought  
>> to be given thought. Would a separate mark-up mechanism be best for  
>> addressing this, as opposed to using ae:inline? I am not so sure.  
>> In any case, I am striving to at least be methodical about giving  
>> up on the design approach taken by RFC4287 in how it deals with  
>> arbitrary content and in-lining (an entry document in a feed  
>> document).
>
> hope that the draft (never mind the specific element used) would  
> cover this.

Let's first settle the issue of using atom:feed directly inside  
atom:link, since that outcome will affect how we deal with this use  
case.

Regards,
Nikunj

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 16 Jul 2009 14:25:01 +1000

I *think* that #2 isn't allowed, process-wise, because the atom  
namespace is reserved for things done on the standards track (IIRC).

I'd say #1 is the right thing to do; it'll give us experience with the  
issues, use cases, etc.

Cheers,

On 16/07/2009, at 2:20 PM, Nikunj R. Mehta wrote:

> I meant repeating the specification. If atom:feed and ae:feed walk  
> the same way and talk the same way, then why bother creating  
> different things?
>
>>
> Good to hear that. I would argue that we should work towards the  
> goal of eliminating ae:inline so that atom:feed and atom:entry can  
> be directly embedded. What is the best way to get there?
>
> 1. An experimental track RFC (in 2009) that uses ae:inline followed  
> by a standards track RFC that legalizes using atom:feed/atom:entry  
>>> to be given thought. Would a separate mark-up mechanism be best  
>>> for addressing this, as opposed to using ae:inline? I am not so  
>>> sure. In any case, I am striving to at least be methodical about  
>>> giving up on the design approach taken by RFC4287 in how it deals  
>>> with arbitrary content and in-lining (an entry document in a feed  
>>> document).
>>
>> I think it largely depends on how the discussion above goes, but  
>> I'd hope that the draft (never mind the specific element used)  
>> would cover this.
>

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Wed, 15 Jul 2009 21:53:36 -0700

> namespace is reserved for things done on the standards track (IIRC).

I agree with you wholeheartedly.

>
> I'd say #1 is the right thing to do; it'll give us experience with  
> the issues, use cases, etc.

This is why I am not in favor of making too many rules about the  
meaning of ae:inline. So lets stick to using ae:inline as a stop-gap  
arrangement until a standards track solution collapses atom:feed  
directly into atom:link.

>>>> RFC4287. A lot of the meta data specialized for feeds such as  
>>>> link relations (paging), identity, and others would have to be  
>>>> repeated in the new element.
>>>
>>>> namespaces. I see the following usage quite likely, even though  
>>>> it is inadvertent:
>>>>
>>>> carefully tread this space. The approach should make it easy to  
>>>> in-line content if all the content is being homogeneously  
>>>> managed. In other words, it should be possible to copy bits  
>>>> directly if one doesn't allow untrusted DTD entities, serializes  
>>>> everything to UTF-8, starts every Atom document with its own  
>>>> xml:lang and xml:base (and bi-di) metadata, and so on.
>>>
>> My point is simply that the "embedding case" should be trivial,  
>> just like embedding text in atom:content is trivial. Other cases  
>> must be supported, albeit with appropriate metadata.
>>
>>>
>>>