On 05/06/2009, at 1:56 AM, Nikunj R. Mehta wrote:
On Jun 3, 2009, at 6:32 PM, Mark Nottingham wrote:
None of this is your fault; the extension model in Atom isn't
terribly well-specified.
I don't know of anyone else complaining about this. I am not sure
this is the general perception. Can you provide some evidence to
back up this claim?
*shrug* It's just an opinion. However, Atom bucks the trend of well-
designed IETF protocols with its "everything is extensible" approach;
by not designating *how* to extend each possible point, and how that
extension is managed, it leaves extension open to interpretation (as
we see here).
I think this might be because at the time Atom was written, the
extensibility of XML was considered a good thing, and the unspoken
reasoning was "the more extensibility, the better." In practice, I
don't think this is working; there's been lots of discussion along
these lines on-list (e.g., whether to use attribute extensibility,
whether to use entry extensions or atom:content).
Regardless of how you serialise the hierarchy, at some point the
document you're going to end up with will not be very useful to a
generic Atom processor (as deployed today), because the majority of
the information is in extensions. When that happens, it's worth
considering minting a new media type to identify the document, so
that people can differentiate them.
I don't see any reason to mint a new media type for dealing with
extensions such as the one I am proposing in atom-hierarchy-ID. Can
you explain what will break and in what way we are creating an
incompatible extension of Atom to force us out of application/atom
+xml?
I didn't say it would become incompatible; I said that at some point,
you extend a document so much that it's no longer useful or meaningful
to a generic processor. At that point, it's worth *considering* (note
the emphasis, please) identifying the new format with a new media
type, to make it distinct from the old one.
--
Mark Nottingham http://www.mnot.net/
