Sam Ruby wrote:
> [..snip excellent rationale..]
So, a desirable characteristic for a container element would be one in which the default namespace can be set.
That is not a desirable characteristic.
At this point, the discussion can fragment into any number of different directions.
[...]
Another is to declare the use of default namespaces as evil, and rewrite both the document and the content to use explicit namespaces on every element. This may very well be where you and I part ways. If so, peace. Just please give the people who want to use default namespaces the same consideration that I am willing to give those who wish to double escape.
I believe the easiest, most robust, least error-prone approach to this sort of problem is to attempt to eliminate default namespace usage whenever possible. Every time a default namespace is elided system robustness and comprehension are improved - I've never seen it work the other way.
And finally, there is a desire to create a format that can be done entirely with default namespaces, and without the need to rewrite or modify the content.
That is a questionable desire. It leads us directly to promoting the use of a div wrapper to protect XHTML from Atom. Any container format that can so easily damage content we have to enforce a shim to protect it, arguably has a design flaw. Atom is just the most of recent of string of flawed container formats.
So, what would a desirable feed container element be for this scenario? I would suggest that it would be something in the xhtml namespace. If it were in the atom namespace, you would have to do something along the lines of:
<atom:summary xmlns:atom="..." xmlns="...">
Sam is 100% right this is problem. I arrive at a very different conclusion.
If you are still with me, what I am proposing is that the simplest and cleanest solution for people who like default namespaces would be to define the format so that there is an <xhtml:div> element between the <atom:summary> and the xhtml fragment that is being syndicated.
It's interesting you call them out so specifically, but no - default namespaces are the problem. Free your mind, and all that.
This can be solved in a general way, not just for XHTML, by banning the use of default namespaces for Atom elements. That means the Atom format would actively subset XMLNS. I see that as a preferable option to anything presented in this thread.
[Although it's time past for paces, I have one on this computer somewhere for default namespaces, but after I got shouted down last year about xmlns="" I didn't think there was much point. Maybe I'll publish it on April 1st]
In the meantime I support Sam's position, but think we're missing an opportunity to produce a more robust XML container format.
cheers Bill
