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
http://o-micron.blogspot.com
[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:
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/
