Julian Reschke wrote:
Sam Ruby wrote:
Bill de hÓra wrote:
Sam Ruby wrote:
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.
I'd like to see a concrete example where this is a problem. As far as I can tell, the content construct itself can be considered the container, so whether or not a mandatory DIV element is present, there will always be a useable container element.
2) Tim (who uses string concatenation) will have to do more work.
Nothing changes for Tim, he can continue to produce the output he's producing currently.
What Tim is syndicating does not match the content on his site. Without this Pace, the div element would need to be considered part of the content.
3) More feeds will be harder to read (that's why I asked you to experiment with alternate serializations.
Whether something is easier to read seems to be a matter of taste: I certainly prefer a globally scoped XHTML namespace declaration, and no additional DIV elements.
Fair. However, a globally scoped XHTML namespace declaration will require every xhtml tag to be explicitly namespaced.
3) More feeds will be invalid (content in atom namespace)
Perhaps I misunderstand... but this shouldn't result in invalid Atom feeds ever - content areas should be able to hold any-namespace not any-namespace-atom-namespace. Worst case is mangled content when the content is lifted out using namespace aware tools. In other words, the container markup format is just dandy, but the content they carry is potentially trashed. If we condone default namespaces this is what we can expect to happen. We discussed warning people about this broken piece of XML technology last year and it was punted to an Implementors Guide - I'm somewhat unsympathetic now if we find ourselves bitten.
Content type="XML" should be able to hold any type. type="XHTML" should be a valid XHTML fragment.
Perhaps I overreached with the word "invalid", but I am of the opinion that if the type is XHTML that the content should be an xthml fragment.
atom:b and atom:strong elements are examples of things which one would not expect to find in xhtml.
Yes, but there are many other things people may get wrong when producing Atom. In particular, I would tend to trust those who do generate XHTML instead of HTML to get namespace declarations right as well.
I have personally seen such invalid feeds. In large quanties. I've worked with the individuals that have produced such feeds, but ultimately such an approach doesn't scale.
Below are some comments that I just added to the Pace:
"- Requiring the namespace declaration on a particular element means (a) profiling XMLNS, (b) defeating potential space optimizations by having the namespace declaration only once, and (c) breaks XML toolkits that do not provide full control over where namespace declarations appear.
Nothing in this pace requires such a declaration.
- if this pace gets accepted, I would ask for the same DIV container element for HTML content for reasons of symmetry."
Are you suggesting that the following would need to be required for symmetry?
<div> ... </div>
Suggesting this seems petty.
- Sam Ruby
