Project

Profile

Help

Bug #4829

open

Static variable initialised to node values cause run-time failure

Added by John Lumley over 3 years ago. Updated over 1 year ago.

Status:
New
Priority:
High
Assignee:
-
Category:
-
Sprint/Milestone:
Start date:
2020-11-18
Due date:
% Done:

0%

Estimated time:
Applies to JS Branch:
2, Trunk
Fix Committed on JS Branch:
Fixed in JS Release:
SEF Generated with:
Platforms:
Company:
-
Contact person:
-
Additional contact persons:
-

Description

When compiling with the XJ compiler a static variable initialised to a node such as:

<xsl:variable name="t" static="yes" select="doc('testStatic.xml')"/>

where testStatic.xml is:

<foo a="1"  xmlns:b="BBB" b:attribute="" xmlns="Flibbertygibbet">
   <bar/>
</foo>

the generated package contains a component definition:

<co id='0' binds=''>
  <globalVariable name='Q{}t' as='1ND' line='7' .... visibility='PRIVATE' flags='s'>
   <node kind='9' content='&lt;foo xmlns="Flibbertygibbet"  xmlns:b="BBB" a="1" b:attribute=""&gt;&#xA;   &lt;bar/&gt;&#xA;&lt;/foo&gt;' baseUri='....testStatic.xml'/>
  </globalVariable>
 </co>

that is the serialization of the document is held as the content property of a node instruction, with the kind of the node indicated.

If the selection is doc('testStatic.xml')/(*,*/@*) the compilation becomes:

<globalVariable name='Q{}t' as='*N' line='7' ....visibility='PRIVATE' flags='s'>
  <literal count='3'>
    <node kind='1' content='&lt;foo xmlns="Flibbertygibbet" xmlns:b="BBB" a="1" b:attribute=""&gt;&#xA;   &lt;bar/&gt;&#xA;&lt;/foo&gt;' baseUri='..../testStatic.xml'/>
    <node kind='2' localName='a' content='1'/>
    <node kind='2' localName='attribute' prefix='b' ns='BBB' content=''/>
   </literal>
  </globalVariable>

Execution of a reference to this variable in SaxonJS2 throws an error as there is currently no support for a node instruction.

There appear to be two routes to solution:

  1. Converting the export to a nested set of aleady supported node construction instructions elem, att, text etc, which will be very costly and increase the export size considerably.
  2. Add support for a node instruction, using the implementation code for parse-xml() when necessary

The latter seems much more sensible.


Related issues

Related to Saxon - Bug #4035: Exporting a stylesheet containing node-valued static variablesClosedMichael Kay2018-11-19

Actions
Actions #1

Updated by Michael Kay over 3 years ago

I thought we had an open issue on this, but I can't find it.

I think we should probably ban it. While we can handle some simple cases by putting a serialization of the node into the SEF file, it doesn't handle the general case, where for example $x is bound to a document node, and $y is bound to $x/*. We then get to the kind of problem that Java serialization faces, of serializing a general graph with arbitrary relationships between the nodes. Unless we're going to do that properly, I don't think we should do it at all.

A simple rule (you can't export a stylesheet if there are static variables bound to nodes) is easier to understand than a more complex set of restrictions.

Actions #2

Updated by Michael Kay about 3 years ago

  • Related to Bug #4035: Exporting a stylesheet containing node-valued static variables added
Actions #3

Updated by Michael Kay about 3 years ago

This was actually covered on the Saxon-J side by bug #4035. To resolve that bug (on the Java side) we added capability to export node-valued static variables to a SEF file in Saxon-J, but we didn't add the corresponding code to import them in Saxon-JS.

Actions #4

Updated by Community Admin about 3 years ago

  • Applies to JS Branch 2 added
  • Applies to JS Branch deleted (2.0)
Actions #6

Updated by Norm Tovey-Walsh almost 2 years ago

  • Priority changed from Normal to High
  • Sprint/Milestone set to SaxonJS 3.0
Actions #7

Updated by Debbie Lockett over 1 year ago

  • Applies to JS Branch Trunk added

The nodejs unit test iss4829 was added on the main branch a while ago (2022-05-27).

The test passes when the test stylesheet is XX-compiled, but fails when XJ-compiled. E.g. when compiled with SaxonJ 11.4, we get the following error at run-time:

Internal error: Unknown expr: node parent=undefined

Please register to edit this issue

Also available in: Atom PDF Tracking page