On 05/06/2009, at 9:38 AM, Nikunj R. Mehta wrote:
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.
XML is just a metamodel and syntax for expressing a language; it's up
to the language to define how to extend itself...
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.
I think HTML is a different case; you can extend it with new elements
that have no meaning in HTML, but it can still be functional HTML, in
particular because you can embed scripts to interpret those new
elements. Atom doesn't have this option, and is more structured, as
well as more intended for machine interpretation in the cases that
people are talking about here. Distinct media types are useful, and we
shouldn't be afraid of them, except perhaps where they cause legacy
problems (as with HTML).
My understanding was that the utility of this extension was being able
to express graphs of entries in a single document; that's why it
sounded so different to me. (as opposed to just adorning a feed with
additional metadata, which is the typical use case for extensions in
Atom). Also, as I think I said earlier, there are a lot of things that
could be improved in Atom (especially for the machine-oriented cases)
if we had a chance to do that.
Anyway, sounds like we understand each other.
Cheers,
--
Mark Nottingham http://www.mnot.net/
