On Jun 4, 2009, at 4:14 PM, Mark Nottingham wrote:
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).
Hmm... while Atom's current extensibility points are sufficient for
what we are attempting to do, I interpret your points as more general
issues with XML, rather than specifically with Atom. I also interpret
broken extensibility along the lines of XSD rather than having too
many options. However, I can now see your perspective as well.
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.
IMHO, anyone would be reluctant to consider a new media type for XML
feeds if the kind of reaction about the ownership and meaning of text/
html is any indication. We should exhaust all options before resorting
to minting a new media type. And the kind of extension we are
suggesting seems legal, prevalent, and useful. Also, it is primarily
additional semantics that are compatible with existing semantics. So I
was a little surprised to see you projecting as far out as you did.
But I have noted your emphasis and, hopefully, communicated my
concerns too.
Regards,
Nikunj
