Thursday, April 13, 2006, 8:24:48 AM, Thomas Broyer wrote:
>> c. Create a new replies extension element >> <thr:replies href="..." >> type="..." >> hreflang="..." >> title="..." >> count="..." >> when="..." /> > -0.5, it *is* a link thr:in-reply-to is a "link" too. An extension element was used for thr:in-reply-to, because atom:link wasn't up to the job. atom:link isn't up to the job for "replies" either. I think that slavishly adhering to convention, at the cost of interoperability is unwise. I'm bothered about this because I think requiring people to process undefined foreign markup is harmful to Atom. With something like an XHTML document, the only sensible way to process it is by using XML tools. XPath, XSLT, whatever - they work well. With Atom, an "Atom Feed Document" alone isn't very useful. Almost all applications will work in terms of Atom Feeds - streams of entries, and feed metadata. To process this, you need to think of Atom in terms of entities: Feeds and Entries, not a set of XML Feed documents. Implementations are based on OO classes and databases, and model entries in terms of titles, content, links, extensions etc. The Atom RFC is clear enough, that you can model an Atom Feed in terms of OO classes, rather than XML documents without losing any data. This all falls apart when people sprinkle the XML with undefined markup that can't be represented outside the context of an XML document. -- Dave
