Project

Profile

Help

Bug #4893

closed

Bug #4693 not yet solved for a different test file

Added by Gerben Abbink about 3 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Diagnostics
Sprint/Milestone:
-
Start date:
2021-02-05
Due date:
% Done:

100%

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

Description

A few months ago I reported bug #4693 for test file "conflict-resolution-0702.xsl". The problem was solved, it no longer appears in release 10.3.

However I have found another test file that still has the same problem, even in release 10.3.

The test file is "bug-47.xml":

<?xml version="1.0" encoding="iso-8859-1"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
 <xsl:template match="*">
   <xsl:apply-templates/>
 </xsl:template>

<xsl:template match="@*|node()">
</xsl:template>

<xsl:template match="text()">
</xsl:template>

</xsl:stylesheet>

Actions #1

Updated by Michael Kay about 3 years ago

  • Category set to Diagnostics
  • Assignee set to Michael Kay

With union patterns of the form @*|node(), we're not attempting to maintain the original text of each of the sub-patterns when the template rule gets split into two separate template rules, so the display form of the pattern needs to be reconstructed from its compiled form. I can't see an easy answer to that. The best we can probably do is to recognise some simple patterns (such as the compiled form of node()) and do a better job of reconstructing a "best guess" string representation. I guess in principle we could try and maintain the original form in the depths of the parser - which would then be handling expressions as well as patterns. This would have diagnostic value in other areas but it's a lot of extra work.

However, your re-opening of this issue has revealed another problem, which is that the patch for the 10.x branch hasn't been fully applied to the 11.x development branch.

Actions #2

Updated by Michael Kay about 3 years ago

I have made a couple of further changes on the 10.x branch:

(a) In a MultipleNodeKindTest (such as you get from a pattern like @*|*) I'm representing each of the parts using its "short string" representation (so "*" rather than "element()")

(b) I've cut out the unnecessary parentheses in the output

(c) The MultipleNodeKindTest corresponding to "node()" is now output as "node()" (even if it didn't originate as "node()".

That's probably the best I can do for now. Keeping open until the changes are all applied on the 11.x branch.

Actions #3

Updated by Michael Kay about 3 years ago

  • Applies to branch 10, trunk added
  • Fix Committed on Branch 10 added
Actions #4

Updated by Michael Kay about 3 years ago

I commented above that it's difficult to maintain the original text for the branches of a union pattern when we split a template rule into two. I'm just thinking that this is a classic "perfect is the enemy of the good" argument. We're talking about diagnostics here, so the aim is to be good, not to be perfect. For the vast majority of patterns, we can say that if the original text of a union pattern contains a single "|" symbol, then we can simply split on that symbol to get the original text of the two component patterns.

Actions #5

Updated by Michael Kay about 3 years ago

  • Status changed from New to Resolved
  • Priority changed from Low to Normal
  • Fix Committed on Branch trunk added

Now fixed on the 11.x branch as well.

Actions #6

Updated by O'Neil Delpratt about 3 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 10.5 added

Bug fix applied to Saxon 10.5 maintenance release.

Please register to edit this issue

Also available in: Atom PDF