Project

Profile

Help

Bug #1640

closed

TypeError if xsl:output method="xml" is used for the boot stylesheet

Added by Manfred Staudinger over 11 years ago. Updated about 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Sprint/Milestone:
-
Start date:
2012-10-31
Due date:
% Done:

0%

Estimated time:
Platforms:

Description

If I use xsl:output method="xml" (either explicit or implicit) in the boot stylesheet (@test_br_1.xsl@) then a TypeError is thrown by the browser [1] as soon as the initializing Saxonce.nocache.js is executed. This is demonstrated by the attached test (@test_br.xml@).

If I change the output method to html (as shown in sample.boot.xsl [2]), then at least Saxon-CE works correct. But most browsers handle the line break elements (@
@) coming from the input or from the XSLT 1.0 stylesheet wrong: many line breaks get doubled, only Firefox seems to get this right. This too can be demonstrated with the attached test. Other self-closing elements may also cause problems.

Maybe I overlook something trivial. I'm not after any serialization and I can easily change my stylesheet to test anything you propose. What I can't change easily (at least in the short run) is the input XML (about 20.000 documents). For a workaround I used Saxon-CE with

<xsl:template match="html:br[preceding-sibling::node()[1][self::html:br]]" mode="init"/>

[1]

Platform Win32 System Windows XP

Opera Version 12.02 Build 1578

[27.10.2012 12:07:56] JavaScript -

http://test.rudolphina.org/RegestTest/test_br.xml

Event thread: DOMContentLoaded

Uncaught exception: TypeError: Cannot convert 'm.body' to object

Error thrown at line 14, column 114 in I() in

http://test.rudolphina.org/SaxonceDebug/Saxonce.nocache.js:

m.body.appendChild(a);

called from line 16, column 101 in () in

http://test.rudolphina.org/SaxonceDebug/Saxonce.nocache.js:

I();

Other browsers give simmiliar messages:

Firefox 16.0.2

TypeError: a.style is undefined

Saxonce.nocache.js Line: 14

Google Chrome Version 23.0.1271.52 beta-m

Uncaught TypeError: Cannot set property 'cssText' of null

Saxonce.nocache.js:14

Safari 5.0 (7533.16)

TypeError: Result of expression 'a.style' [null] is not an object.

Saxonce.nocache.js:14

[2] http://www.saxonica.com/ce/doc/starting/running/pi-sample.xml


Files

test_br.xml (426 Bytes) test_br.xml Manfred Staudinger, 2012-10-31 16:07
test_br_1.xsl (1.27 KB) test_br_1.xsl Manfred Staudinger, 2012-10-31 16:07
test_br_2.xsl (1.05 KB) test_br_2.xsl Manfred Staudinger, 2012-10-31 16:08
Actions #1

Updated by Michael Kay over 11 years ago

  • Status changed from New to In Progress
  • Assignee set to Michael Kay
  • Priority changed from Low to Normal
  • Found in version set to 1.0

Thanks for reporting it, we'll look into it.

A lot of this is outside our control, as far as I can see. The execution of the boot stylesheet is under the control of the native XSLT 1.0 processor in the browser. I would have thought this should always use method="html", as HTML is what it is generating (though if the processor isn't serializing the output - which is the case with Firefox - then it shouldn't matter what xsl:output says - in theory at any rate).

Actions #2

Updated by Michael Kay over 11 years ago

What isn't clear to me is why your boot stylesheet is trying to copy the XML source into the HTML page. This isn't what our sample boot stylesheet at http://www.saxonica.com/ce/doc/starting/running/pi-sample.xml does: it merely creates a skeletal HTML page that then invokes Saxon-CE to process the XML source.

Actions #3

Updated by Manfred Staudinger over 11 years ago

I was starting with source XML files each of which contain cross-references in the form of sequences of link elements (@@) or sequences of comma separated character strings. Those are all valid XHTML markup plus some control information in my private namespace and are processed with the browsers own XSLT 1.0 engine which is started from a <?xml-stylesheet?> processing-instruction.

The first stage in migrating the site was to replace the JavaScript by Saxon-CE and was a big success. The code is much cleaner, easy to maintain, without CSS tricks. The only downside is the lost ability for users to work with JavaScript disabled.

This leaves a lot of still complex processing for XSLT 1 and I had hoped for a coexistence of the browsers XSLT 1 engine and Saxon-CE, at least for a while. The migration, which for sure will also involve changes in the source XML, could be done in smaller stages and the reaction of the users used for the next stage.

If with HTML5 the DOM for HTML and XHTML is the same, how would it possible for Saxonce.nocache.js to get a TypeError for one case and not the other? Do you see any other possibility to run Saxon-CE after an initial XSLT 1 (with output XML)?

Actions #4

Updated by Manfred Staudinger over 11 years ago

Hopefully I have found a solution for xsl:output method="html"@: If I change creating an @<br/> element from

<xsl:element name="br"/>

<xsl:element name="br" namespace=""/>

and also add a template

<xsl:template match="html:br">
   <xsl:element name="br" namespace=""/>
</xsl:template>
Actions #5

Updated by O'Neil Delpratt about 11 years ago

  • Status changed from In Progress to Closed

Please register to edit this issue

Also available in: Atom PDF