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 protected]>
Date: June 29, 2009 2:08:41 PM PDT
To: [email protected]
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/
