Support #5209


Should net.sf.saxon.expr.Expression.extraProperties be also copied when the net.sf.saxon.expr.Expression.copy(RebindingMap) method is invoked?

Added by Radu Coravu 4 months ago. Updated 3 months ago.

Start date:
Due date:
% Done:


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


Tihis just a remark, it's not something we need. We've kind of been patching Saxon a little bit for our debugger and are using Expression.extraProperties to keep a reference from the expression to the StyleElement from which it was generated. I know it's not the reason why Expression.extraProperties but we found it interesting for this particular need we had to pair the Expression received on the trace listener with the StyleElement from which it originates. Looking at implementations like this "net.sf.saxon.expr.LetExpression.copy(RebindingMap)" shouldn't the copy of any expression by default also copy the extra properties?

For now I will make changes to "net.sf.saxon.expr.instruct.TraceExpression.copy(RebindingMap)" and copy the extra property we are interested in from the original to the copy.

Actions #1

Updated by Michael Kay 4 months ago

Good question with no easy answer. Most of the properties on the expression tree, including most of the extraProperties, are computed lazily and will be re-computed if not present. Not copying the property is therefore probably safer in general, because an expression copy is always happening in the middle of an expression rewrite that has the potential to change the value of the properties. But obviously some properties, like your link back to the source tree, are not like that, and cannot be reconstituted if lost.

I wonder if you wouldn't be better off relying on the Location object for a link back to the source element?

I think that if you set Feature.RETAIN_NODE_FOR_DIAGNOSTICS, the Location of expressions should be an AttributeLocation in which the elementNode property points to the source element. Give it a try, anyway!

Actions #2

Updated by Radu Coravu 4 months ago

Thanks for the feedback Michael. About using on the trace listener the Location of the Traceable to get to the StyleElement, it depends, sometimes it is an instance of "net.sf.saxon.expr.instruct.TemplateRule" and sometimes it is an "net.sf.saxon.expr.parser.XPathParser.NestedLocation" The "NestedLocation" is indeed wrapped around an AttributeLocation which could give us access to the node info. So an interesting idea, in at least some cases (maybe most cases) we could use the location to map the Traceable to the style element. Anyway I guess this can be closed for now.

Actions #3

Updated by Radu Coravu 4 months ago

Also sometimes the locations are instance of "net.sf.saxon.expr.parser.Loc" but this seems to occur when they are not really connected to a NodeInfo. For example in this case:

<xsl:template match="parent">
    <xsl:element name="name1">

for that "textr" node the trace listener receives a "net.sf.saxon.expr.instruct.ValueOf" with a "net.sf.saxon.expr.parser.Loc" but in a way this probably makes sense as there is no StyleElement associated to the text node.

Actions #4

Updated by Michael Kay 3 months ago

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

Closing this with no further action.

I think it's safer for expressions NOT to copy the extraProperties, and I would recommend using the Location property to hold information enabling you to trace back to the source code.

Please register to edit this issue

Also available in: Atom PDF