XSLTForms.xsl transform drops the XHTML namespace

[Conal-Tuohy]

I've recently upgraded to the latest version of XSLTForms (rev.638) and discovered that the output of the stylesheet does not use the XHTML namespace. By processing my XHTML + XForms document with XSLTForms, I've stripped the namespace from it. This was a problem for me because I am executing XSLTForms.xsl in an XProc pipeline, server-side, rather than in the browser, and subsequent stages in the pipeline were expecting an XHTML document.

My work-around is to rename the default namespace from "" back to "http://www.w3.org/1999/xhtml" after the XSLTForms.xsl transformation:

<p:namespace-rename from="" to="http://www.w3.org/1999/xhtml" apply-to="elements"/>

But I wonder if the elimination of the XHTML namespace by XSLTForms.xsl is intentional, or if it's just a bug? If intentional, what does it achieve?

[AlainCouthures]

XHTML support in browsers is not good nowadays so its elimination was effectively intentional.

Modifying xsltforms.xsl for producing XHTML as before should not be a problem but, luckily, your proposed workaround with XProc looks great!

[Conal-Tuohy]

Thanks Alain!

For me, the value of the xmlns is in clarity of processing mixed-namespace markup server side, and in being able to reuse stylesheets I already have which target XHTML. I can post-process the output of XSLTForms.xsl, though, so that's not actually a problem.

I am curious about the XHTML issues you refer to though:

XHTML support in browsers is not good nowadays

Do you have any pointers to more (and current) information? I have done some Googling but I've found mostly web pages dating from ancient times. I usually rely on caniuse.com to tell me what's safe to use, and it's pretty reassuring about XHTML served as application/xhtml+xml. I haven't had any trouble with it, myself.