Re: new XSLT output methods, was: several messages

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 UTC