Anne van Kesteren wrote:
Sam Ruby wrote:
Ok, now that I'm thinking about this more, I'm changing my initial +0 to +1. This just makes sense. There does need to be a container for the XHTML and div is a solid, logical choice. I don't think it should matter where the xmlns is declared... any ancestor element will do.
I'm still -1. But I was wondering, why only ancestor elements? Wouldn't the most logical thing for "string based generators" be to apply it on the DIV element?
I'm confused. If you are opposed to this pace, then what div element?
That was a question in reply to what James wrote. It appeared to be an error.
It may also be helpful to look at a specific feed, for example this one:
http://www.imc.org/atom-syntax/mail-archive/msg12902.html
Experiment with alternate serializations if you like.
The important question is whether the <div> element is part of the format or part of the content? Should aggregators copy it? When an Atom entry is POSTed to a blog, is the div part of the content?
If the page is adopted, which I hope not, it MUST NOT be part of the content. If the page is not adopted it MUST be part of the content.
I can easily sit back and adopt a "wait and see" and "I told you so" attitude, but by now it should be obvious that I care too much about the success of this format and protocol to do that.
If this Pace is not adopted, the following predictions can be made:
1) Graham (who uses proper XML tools) will have to do more work.
2) Tim (who uses string concatenation) will have to do more work.
3) More feeds will be harder to read (that's why I asked you to
experiment with alternate serializations.
3) More feeds will be invalid (content in atom namespace)
4) More feeds will be incorrect (in the sense that Tim's feed does
accurately reflect the content of his entries).
5) For some combinations of clients and servers, entries produced
via an HTTP POST will end up with multiple <div>s.Meanwhile, now that the location where the namespace can be declared details have been removed from this pace, Henri can continue to do a DOM-to-DOM copy.
I stand by my original statements:
There are cases where explicit is better than implicit.
Given that common practice is to include this element, making it mandatory makes things clearer to both people who are producing consuming tools based on the spec, and people who are producing new feeds based on copy and paste.
- Sam Ruby
