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

new XSLT output methods, was: several messages

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 04 Sep 2008 09:28:24 +0200
Message-ID: <48BF8E18.2020203@gmx.de>
To: "Michael(tm) Smith" <mike@w3.org>
CC: public-html@w3.org

Michael(tm) Smith wrote:
> Julian Reschke <julian.reschke@gmx.de>, 2008-09-03 13:11 +0200:
> 
>>  Thomas Broyer wrote:
>>> Also, XSLT cannot generate DOCTYPE internal subsets or entity
>>> references, and people have accomodated; using the xsl:text trick if
>>> they really needed those things, so why couldn't they also accomodate
>>> using the xsl:text trick to output the HTML5 doctype?
>>  You need disable-output-escaping, which is optional.
> 
> Do we actually know of any XSLT implementations that don't support
> disable-output-escaping?

1) I recall one that didn't at all, but I forgot which one it was.

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).

3) An author may be able to edit the XSLT source, but the invocation may 
be done by code (s)he doesn't control (let's say an XSLT hook in a 
content management system). d-o-e is only going to work when it's the 
*last* transformation in a set of transformations. Many systems allow 
pipelining of transforms. Yes, these issues can be fixed by updates, but 
why are we making things harder to deploy than needed?

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.

BR, Julian
Received on Thursday, 4 September 2008 07:29:12 GMT

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