What I said was very clear... It is simply this: IF you are going to define ae:inline in terms of atom:content then you must accept the added complexity that requires. However, personally I'm not convinced that ae:inline is a good idea in any form or with any level of complexity. The non-theoretical benefits of a generic ae:inline or of a hierarchical atom syntax have escaped me thus far.
- James ------Original Message------ From: Nikunj R. Mehta To: James M Snell Cc: atom-syntax Syntax Subject: Re: New Version Notification for draft-mehta-atom-inline-00 Sent: Jun 10, 2009 1:24 PM Nikunj http://o-micron.blogspot.com On Jun 10, 2009, at 1:22 PM, James M Snell wrote: > > > Nikunj R. Mehta wrote: >> <snip> >>>> >>>> I am glad you are speaking up about this. The original proposal >>>> for in-lining as expressed in draft-divilly-atom-hierarchy-01 was >>>> rather modest and supported a rather simple use case. >>>> >>>> However, per Mark Nottingham et al [1], the use of the ae:inline >>>> is held up as the right way of extending Atom. Plus, per James >>>> Snell [2], the inline content's media type is better gleaned from >>>> ae:inl...@type attribute. Also, per Al Brown et al. [3] [4] [5], >>>> it was more important to ensure maximum flexibility than >>>> demonstrate specific use cases. >>>> >>> To be clear, what I was suggesting was that if you were going to >>> be pointing to the atom:content rules as the model for processing >>> ae:inline then it would better for ae:inline to have its own type >>> attribute distinct from the atom:link elements type attribute. >>> How to handle things if there is a mismatch between the atom:link/ >>> @type and the ae:inline/@type (or the atom:link/@type and the >>> actual content type of the linked resource after performing an >>> HTTP GET) is a separate issue altogether. >> >> Do you find the current I-D text satisfactory or do you agree it is >> more complex than it needs to be? >> > For the "up" and "down" links yes, I think it's much better. "up" and "down" links are not defined in atom-inline. This thread is actually seeking feedback on atom-inline only. That leads me to think that you are in favor of the current complexity in the in-line content model. > As for ae:inline, I like that it has been separated out into a > separate I-D but I am still definitely on the fence about whether in- > lining is even something that should be done. I've never liked the > idea of making the Atom syntax hierarchical and I haven't seen > anything yet that has convinced me otherwise. > This is an experimental I-D that seeks to formalize and harmonize what has already been offered commercially. It would be useful to know about your concerns so that we can experimentally validate them. Sent from my Verizon Wireless BlackBerry
