See below...

http://www.kirit.com/

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:owner-atom-
> [EMAIL PROTECTED] On Behalf Of David Powell
> Sent: Thursday, April 13, 2006 4:49 PM
> To: Thomas Broyer
> Cc: Atom-Syntax
> Subject: Re: Feed Thread Draft Updated
> 
> 
> 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.

This depends on what sort of application you're building though. As a content 
publisher it doesn't really make that much difference as I will choose the 
markup that I feels best represents my internal data and models (and which I 
think will be best understood and most relevant to my audience).

If I am writing a desktop display tool then I'll work out which extensions are 
going to be of most use to somebody reading the contents of the feed. I'll 
probably ignore all sorts of things that are not relevant or I don't 
understand. My OO model is going to reflect what I'm going to draw on screen 
and so long as I can map incoming feeds to show them it's fine.

The problem comes where I'm writing something that's going to repackage feeds. 
If I make the decision to preserve as much of the original markup then I have 
to allow for that in my internal models. I may however take the view that the 
audience that I'm repackaging the feeds for want me to transform it and that's 
part of my service.

If I as a publisher have chosen to use some weird markup that maybe I've 
invented then that's my lookout. I should really make sure though that the feed 
is understandable at least on a basic level with just core Atom markup. If I 
can't do that then Atom may not be the best medium for me to publish in.


K

Reply via email to