Friday, May 5, 2006, 4:05:15 AM, Tim Bray wrote:
> Give me a break, we're in the first *days* of something that will be > used for at least decades. Todays' APIs will have a vanishingly- > small lifespan in comparison The issue isn't that an implementation is at fault. The issue is that a implementation is not at fault, is behaving reasonably, and yet still wouldn't be compatible with the extension. As I said 12 months ago <http://www.imc.org/atom-syntax/mail-archive/msg15795.html>: | The problem with section 6 is that we define 3 different classes of | non-Atom markup, but don't say why we've done that, or help authors to | know which type they should choose when they write a document. | [...] | It doesn't really make sense we have thought out how to extend | atom:feed, atom:entry, atom:author etc, but atom:link is a sub-RSS | free-for-all. Section 6 was received inadequate review. Perhaps someone can tell me now, why there are three different classes of non-Atom markup? Section 6 came about due to a clash between people who see Atom as an XML document format like XHTML ([1] choice 1), and people who see Atom as a serialisation of feed and entry concepts, that span multiple XML documents ([1] choice 2). Section 6 satisfies neither party. [1] http://www.mnot.net/blog/2004/05/12/on_infosets The distinction between Simple and Structured extensions was a well meaning, but misguided, effort to provide a lower bar for extension support for implementations that would find it unfeasible to preserve the full Infoset and xml:lang/xml:base context. > crippling our expressiveness "...and conservative in what you send". That is the point here. What percent of stateful feed stores do you think support all of Atom's core elements? How many handle xml:lang and xml:base correctly for core elements? - less? How many handle simple extensions? - less? How many handle structured extensions, including ones that require that the xml:base and xml:lang context is preserved? - less? How many handle arbitrary attributes on any Atom element, and arbitrary XML in atom:link? - less? How many preserve the order of elements for any future extensions that choose to make order significant? - less? How many cope with extensions that follow our example of "inheritance", and maintain feed extensions as they were at the time of the document that the entry was last delivered with for the benefit of "inheritable" feed extensions, whilst also maintaining an association with the latest feed metadata for the benefit of "true" feed extensions? - less? How many preserve the namespace mappings for any future extensions that choose to use QNames in content? - less? How many preserve PIs and comments for any future extensions that make use of them? - less? Atom doesn't define any conformance levels for the preservation of content and extensions, so extension designers are forced to consider the consequences themselves. If you're happy working with XML APIs over a set of polled feed documents (together with their preserved URIs, Content-Locations, entity headers and retrieval dates), then none of this matters. If you see a benefit of providing a higher level abstraction over feeds and entries, an OO API, an RDBMS schema, an APP implementation, or any value-added feed processing service, then it is worth considering the practicalities of such support and employing a bit of conservatism. -- Dave
