Joerg Heinicke wrote:
On 16.03.2007 21:52, Grzegorz Kossakowski wrote:
Moreover, I wonder why we need special XHTMLSerializer? As XHTML is
only XML with special namespace and tag set why we don't use just
normal xml serializer and configure proper mime type? Do I miss
something important?
If you have a look into the source code [1] you can see that it handles
(besides the stuff fixing the tag soup) doc type, mime type and has same
special XHTMLEncoder [2], which adds the HTML 4 entities. So far
absolutely ok.
It puts every element in no namespace into the XHTML namespace. Still
acceptable, but abdicable - it's for the lazy guys.
If by "the lazy guys" you also mean Cocoon itself. For instance, the
CForms forms-field-styling.xsl creates all its output in the null
namespace, which is fine for regular HTML delivery but if for some
reaason you do want to deliver as XHTML you have to set the proper
namespace somehow.
Also the meta tag
for content type it adds should be abdicable. AFAIR it's also only for
IE as it stumbles on the XML declaration.
But at the end it should not do more than this.
To interject a counter-opinion, there is a well-established precendent
on the Web today for delivering XHTML in ways that are consumable by
current-day user agents but without sacrificing the well-formedness or
validity of the XML. True, you have to control certain aspects of the
serialization to avoid tripping up certain browsers, which can be a bit
of a pain. But I think the end result is a good one: more documents get
published as true XML but can still be consumed by non-XML user agents.
In fact this compatibility was an important consideration when XHTML
1.0 was created, and there is an entire appendix in the W3C
Recommendation dedicated to the subject [1].
Now, XHTMLSerializer is a tool for publishing XHTML. Adopting a
hard-line attitude and deliberately ignoring those things that can be
(fairly easily) done to make the XHTML consumable by current-day user
agents greatly decreases the usefulness of that tool. I think there's a
lot of value in having the tool handle these things transparently rather
than making users figure out workarounds themselves.
--Jason
[1] http://www.w3.org/TR/xhtml1/#guidelines
