Project

Profile

Help

Bug #5443

closed

Missing namespace prefix in error message

Added by Ken Holman over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
Diagnostics
Sprint/Milestone:
-
Start date:
2022-04-03
Due date:
% Done:

0%

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

Description

Hi, folks!

In my stylesheets I have the following code, focusing on the assignment of the element "$c:f/c:missing" to a variable:

<xsl:template name="c:MainFrontCoverContent">
  <xsl:param name="c:f" as="document-node()+" tunnel="yes"/>
  <wrapper x:h="div*cover-page">
    <!--FRONT COVER PAGE(S)-->

    <!--Set colour palette to use-->
    <xsl:variable name="c:colourBase" as="element()" select="
        if ($c:isDraft) then
          $c:coversInDraft
        else
          if ($c:inColour) then
            $c:f/c:missing
          else
            $c:coversInBW"/>

    <!--Top background with photo/image if applicable. The same
      photo/image can be used on front and back covers or a separate
      photo/image can be used for each cover according to the name.-->
    <block-container absolute-position="fixed" left="10mm" right="10mm" top="10mm"
      bottom="175mm" margin="0mm" padding="0mm"
      background-color="{$c:colourBase/@c:topBackground}" z-index="0">
     .....

In the expected error message (because the element "c:missing" is missing as a child of the variable $c:f), you can see that instead of reporting "$c:f/c:missing" the report reads "$c:f/missing". The namespace prefix of the child is not there:

     [echo] Type error evaluating (docOrder($c:f/missing)) in xsl:variable/@select on line 204 column 30 of NORSOKcover.xsl:
     [echo]   XTTE0570: An empty sequence is not allowed as the value of variable $c:colourBase
     [echo] at template c:MainFrontCoverContent on line 191 of NORSOKcover.xsl:
     [echo]      invoked by xsl:call-template at file:/Users/admin/u/git/render/render/SD/SDpage.xsl#269
     [echo]   In template rule with match="std-meta[("SD",...) = c:metaOriginator(...)][parent::front]" on line 237 of SDpage.xsl
     [echo]      invoked by xsl:apply-templates at file:/Users/admin/u/git/render/render/support/Realta-sts2fo-a4-base.xsl#495
     [echo] at template c:doAdoptionStandardLayer on line 475 of Realta-sts2fo-a4-base.xsl:
     [echo]      invoked by xsl:call-template at file:/Users/admin/u/git/render/render/support/Realta-sts2fo-a4-base.xsl#423
     [echo]   In template rule with match="standard" on line 419 of Realta-sts2fo-a4-base.xsl
     [echo]      invoked by xsl:next-match at file:/Users/admin/u/git/render/render/support/Realta-sts2fo-a4-base.xsl#406
     [echo]   In template rule with match="standard" on line 405 of Realta-sts2fo-a4-base.xsl
     [echo]      invoked by xsl:next-match at file:/Users/admin/u/git/render/render/support/Realta-sts2fo-a4-base.xsl#388
     [echo]   In template rule with match="standard" on line 383 of Realta-sts2fo-a4-base.xsl
     [echo]      invoked by xsl:next-match at file:/Users/admin/u/git/render/render/support/force-sts.xsl#90
     [echo]   In template rule with match="*" on line 81 of force-sts.xsl
     [echo]      invoked by xsl:apply-templates at file:/Users/admin/u/git/render/render/support/Realta-sts2fo-a4-base.xsl#359
     [echo]   In template rule with match="/" on line 304 of Realta-sts2fo-a4-base.xsl
     [echo]      invoked by xsl:next-match at file:/Users/admin/u/git/render/render/support/Realta-sts2fo-a4-base.xsl#275
     [echo]   In template rule with match="/" on line 227 of Realta-sts2fo-a4-base.xsl
     [echo] An empty sequence is not allowed as the value of variable $c:colourBase

In the attached I've attempted to replicate the error, because I cannot send you the 19 stylesheet fragments in the entire stylesheet tree.

Unfortunately, the error message does not read the same:

~/t/saxonica $ saxon9he -s:error-message.xsl -xsl:error-message.xsl 
working
Type error at char 114 in xsl:variable/@select on line 60 column 30 of error-message.xsl:
  XTTE0570: An empty sequence is not allowed as the value of variable $c:colourBase
  at xsl:call-template name="c:MainFrontCoverContent" (file:/Users/admin/t/saxonica/error-message.xsl#28)
An empty sequence is not allowed as the value of variable $c:colourBase
~/t/saxonica $ 

Instead of:

Type error evaluating (docOrder($c:f/missing)) in xsl:variable/@select ...

I can get only:

Type error at char 114 in xsl:variable/@select ...

Perhaps you know how you can trigger the internal docOrder() function ... I'm not sure what part of my code in my production stylesheet does so.

Anyway, I found my problem, so the issue is of low priority ... but perhaps the fact that the reported argument to docOrder() isn't reported precisely correct might be something that needs looking into.

I hope this is helpful!

. . . . . Ken


Files

error-message.xsl (2.3 KB) error-message.xsl Ken Holman, 2022-04-03 20:02
Actions #1

Updated by Michael Kay over 2 years ago

Internally, this will be an AxisExpression containing a NameTest, and a NameTest holds only a name code, from which we can reconstruct the namespace URI and local name (by reference to the name pool), but we can't generally reconstruct the prefix because it's not needed operationally. I would have expected, however, to see either the full EQName in Q{uri}local format, or an abbreviation of it.

The purpose of the reconstructed string in the error message is to help people identify where the problem occurred; we're not trying to give a faithful representation of the original expression. The fact that it's an approximation isn't anything to worry about.

As for docOrder(), Saxon compiles A/B as docOrder(SlashExpression(A, B)), where docOrder eliminates duplicates and sorts into document order; the type checking and optimization phases then try hard to remove the docOrder() operation if analysis shows that it can be skipped (either because the expression is already sorted, or because the order doesn't matter). The conditions under which it is able to do this analysis are rather complex.

Actions #2

Updated by Ken Holman over 2 years ago

Perfectly acceptable response, Michael, thank you.

Indeed, I did find the problem, as the clue was sufficient.

I was trying only to be helpful in case this was something important.

Case closed!

Actions #3

Updated by Michael Kay over 2 years ago

  • Category set to Diagnostics
  • Status changed from New to Closed
  • Assignee set to Michael Kay

Decided to close this with no action.

Please register to edit this issue

Also available in: Atom PDF