[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: New Version Notification for draft-mehta-atom-inline-01 Nikunj R. Mehta Mon Jul 13 16:30:27 2009

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

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


[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

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


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.


Begin forwarded message:

From: IETF I-D Submission Tool <[EMAIL PROTECTED]>
Date: June 29, 2009 2:08:41 PM PDT
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

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/