Bill de hÃra wrote:
Being explicit about profiling would be good if that's what we're going to do. Being sure that adding features like xml:base and xhtml:div are not more trouble than they're worth is good.
On xml:base, I don't think we actually have a problem with the document architecture. If you're processing an Atom entry you get an (X)HTML fragment and a base URI. The information is there, it's just that it may be difficult to *leave* the Atom format and repurpose it. So, is there something more useful we could provide? Looks like the generic relative/absolute trade-off.
If you've got an embedded HTML library, you can probably deal with it just fine.
If you have a web interface, you get the nasty problem of combining the content into one HTML format and base URI. It might be possible to deal with baseURIs using event bubbling or other JS hacks, but that won't help spiders and such.
The Feedparser approach is fine, but it's definitely not the definition of a 'competant' Atom Processor, energetic as it is. Roundtripping might be more important that HTML munging.
David has previously mentioned xml:base interactions with atom:source. Any other issues?
I guess we could also use a quick survey of xml:base support in parsers, xslt implementations, etc. if we don't already have one. xml:base was supposed to be in XSLT 1.1, and Saxon supports it right now.
Robert Sayre
