W3C home > Mailing lists > Public > public-html@w3.org > September 2008

Re: new XSLT output methods, was: several messages

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 04 Sep 2008 11:49:13 +0200
Message-ID: <48BFAF19.4040308@gmx.de>
To: Thomas Broyer <t.broyer@gmail.com>
CC: "public-html@w3.org" <public-html@w3.org>

Thomas Broyer wrote:
>> 2) For the others, it depends where they transform to. For instance,
>> Transformix in Mozilla doesn't understand it, because it directly builds a
>> DOM (I think).
> 
> So it merely depends on how the DOM will be "interpreted", and in this
> case I guess as XML (or maybe XHTML, as IIRC Mozilla looks at the
> namespace of the root element) ?

Mozilla certainly understands HTML (elements in the empty namespace) as 
well.

> ...
>> 4) And, again, it's not an XSLT-only problem. javax.xml.transform is the
>> most reliable way included in the JDK to produce HTML, and is based on the
>> XSLT serializers. The same situation could apply to other platforms.
> 
> FYI it's the case on .NET with XmlWriter, but a 3rd party lib could
> very well provide its own XmlWriter to output HTML5 or whatever (it's
> actually on my todolist for Twintsam [1])
> ...

Thanks for the info.

So, yes, all this *can* be worked around by using alternative 
implementations. My question remains: is it a good idea to make it 
harder to generate HTML5 as it needs to be?

BR, Julian
Received on Thursday, 4 September 2008 09:49:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:23 GMT