Project

Profile

Help

Bug #2450

closed

Unexpected result using w3c accumulator sample

Added by Philip Fearon over 8 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
XSLT conformance
Sprint/Milestone:
Start date:
2015-08-31
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.6
Fix Committed on Branch:
9.6
Fixed in Maintenance Release:
Platforms:

Description

I'm learning use of XSLT 3.0 accumulators by going through the w3c examples, but I'm getting unexpected output using Saxon 9.6.0.3 PE.

In the example 'Output Hierarchic Section Numbers' - I'm using the following input:

<doc>
  <section>[1]
    <section>[1.1]</section>
    <section>[1.2]</section>
    <section>[1.3]
      <section>[1.3.1]</section>
      <section>[1.3.2]</section>
    </section>       
  </section>
</doc>

Here's the XSLT (the same as the w3c example code - except that the 'accumulator' function name has been substituted with 'accumulator-before')

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:xs="http://www.w3.org/2001/XMLSchema" exclude-result-prefixes="xs" version="3.0">

  <xsl:accumulator name="section-nr" as="xs:integer*" initial-value="0">
    <xsl:accumulator-rule match="section" phase="start" 
      select="0, head($value)+1, tail($value)"/>
    <xsl:accumulator-rule match="section" phase="end" select="tail($value) (:pop:)"/>
  </xsl:accumulator>

  <xsl:template match="node()|@*">
    <xsl:copy>
      <xsl:apply-templates select="node()|@*"/>
    </xsl:copy>
  </xsl:template>
  
  <xsl:template match="section">
    <p>
      <xsl:value-of select="reverse(tail(accumulator-before('section-nr')))" 
        separator="."/>
    </p>
    <xsl:apply-templates/>
  </xsl:template>

</xsl:stylesheet>

The XML output I get is below:

<?xml version="1.0" encoding="UTF-8"?><doc>
  <p>1</p>[1]
  <p>1.1</p>[1.1]
  <p>1.2</p>[1.2]
  <p>1.3</p>[1.3]
  <p>1.3.1</p>[1.3.1]
  <p/>[1.3.2]           
</doc>

The unexpected bit is with the last 'p' element - it has no '1.3.2' text content. Curiously, if I add another section (1.3.3), then all p element text content appears as expected (including 1.3.3)

The standard output from Saxon is given below for info:

Saxon-PE 9.6.0.3J from Saxonica

Java version 1.8.0_25

Using license serial number *******

Stylesheet compilation time: 237.126943ms

Processing file:/Users/philipfearon/Documents/xslt-samples/accumulator-test.xml

Using parser com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser

Building tree for file:/Users/philipfearon/Documents/xslt-samples/accumulator-test.xml using class net.sf.saxon.tree.tiny.TinyBuilder

Tree built in 3.054788ms

Tree size: 22 nodes, 44 characters, 0 attributes

Execution time: 37.320784ms

Memory used: 45693584

NamePool contents: 3 entries in 3 chains. 6 URIs

Actions #1

Updated by Michael Kay over 8 years ago

  • Category set to XQuery conformance
  • Status changed from New to In Progress
  • Assignee set to Michael Kay
  • Priority changed from Low to Normal
  • Found in version set to 9.6

(deleted. Updated wrong bug entry)

Actions #2

Updated by Michael Kay over 8 years ago

  • Category changed from XQuery conformance to XSLT conformance

Sorry for the delay in responding. Progress so far: I have confirmed that the problem exists in 9.6, and not in 9.7.

Examining the internal accumulator values as they are calculated, they appear to be correct in both releases. The problem appears to occur when searching the calculated values to find the one that is applicable to a particular node.

Actions #4

Updated by Michael Kay over 8 years ago

The code is building a table of accumulator values at the points where they change. The table is a list of triples containing in effect (node number, is-post-descent, accumulator-value). To find the accumulator value for a particular node/visit, the code does a binary chop on this table, using an ordering function to decide whether one (node-number, is-post-descent) value represents an earlier or later node visit than another. This ordering function is producing an incorrect result because the value of the is-post-descent flag, under conditions which I haven't precisely determined, is set incorrectly.

Actions #5

Updated by Michael Kay over 8 years ago

  • Status changed from In Progress to Resolved

A patch has been committed on the 9.6 branch (AccumulatorData.java). No patch needed for 9.7.

Actions #6

Updated by O'Neil Delpratt over 8 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in version set to 9.6.0.8

Bug fix applied in the Saxon 9.6.0.8 maintenance release

Actions #7

Updated by O'Neil Delpratt over 8 years ago

  • Applies to branch 9.6 added
  • Fix Committed on Branch 9.6 added
  • Fixed in Maintenance Release 9.6.0.8 added
Actions #8

Updated by O'Neil Delpratt over 8 years ago

  • Sprint/Milestone set to 9.6.0.8

Please register to edit this issue

Also available in: Atom PDF