Re: new XSLT output methods, was: several messages

On Thu, Sep 4, 2008 at 9:28 AM, Julian Reschke wrote:
>
> Michael(tm) Smith wrote:
>>
>> Julian Reschke, 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).

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

> 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?

My opinion is that XSLT shouldn't have ever dealt with serialization
and only with InfoSet-to-InfoSet transformations; but it's not the
case, so I'm leaving this discussion.

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

[1] http://code.google.com/p/twintsam/


-- 
Thomas Broyer

Received on Thursday, 4 September 2008 09:24:29 UTC