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.
