OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Fyi.  Mark's comments are related to our hierarchy discussion tomorrow.
Sent from BlackBerry.


----- Original Message -----
From: Mark Nottingham [mnot@mnot.net]
Sent: 07/13/2009 01:21 PM ZE10
To: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>
Cc: atom-syntax Syntax <atom-syntax@imc.org>
Subject: Re: New Version Notification for draft-mehta-atom-inline-01




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 <idsubmission@ietf.org>
>> Date: June 29, 2009 2:08:41 PM PDT
>> To: nikunj.mehta@oracle.com
>> 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/



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]