[
https://issues.apache.org/jira/browse/XALANJ-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789350#action_12789350
]
Henry Zongaro commented on XALANJ-2510:
---------------------------------------
Adam, I feel very sorry this has degenerated to this point. I have to admit
that the extension function and extension element support in the Xalan-J
interpreter is not the part of the processor that I'm most familiar with. In
fact, at this stage, I'm sure you know it better than I do. That's the biggest
reason why I have expressed my concerns in terms of the XSLT language, and
haven't been able to give you specific detailed suggestions about improvements
to your patch at the implementation level or directed you to individual files
that I think you should change.
My main concern continues to be about the way this integrates with the rest of
the language. The xsl:with-param issue is one part of it. The bigger part is
I don't feel it's reasonable to expect that a user of a programming language
will use a feature in only one way. If I as a user can write,
<xsl:variable name="foo">
<my:extension/>
</xsl:variable>
I would expect to be able to use control flow in the body of the variable, to
select which of several extension elements I want to use:
<xsl:variable name="foo">
<xsl:choose>
<xsl:when test="some-condition">
<my:extension/>
</xsl:when>
<xsl:otherwise>
<some:other-extension/>
</xsl:otherwise>
<xsl:choose>
</xsl:variable>
and I would expect to be able to use named templates for modularity, if
appropriate:
<xsl:variable name="foo">
<xsl:call-template name="do-extension"/>
</xsl:variable>
<xsl:template name="do-extension">
<my:extension/>
</xsl:template>
and in all those cases, I would expect to have the same value assigned to the
variable foo, based on the way existing language features interact with one
another. I don't feel these are bizarre or even unreasonable usage scenarios.
I do have a penchant for creating tests that expose very dark corners of
language specifications that I know would never, ever be tripped across by a
real user, but I don't think these examples fall into that category.
Changing the behaviour of the feature incrementally to match (what I think is)
the expected behaviour runs the risk that some of your users will come to
depend on those differences in behaviour - i.e., they might write stylesheets
that expect your extensions to behave one way when the extension element is a
child of an xsl:variable and a different way when it's the child of an xsl:if
that is itself the child of an xsl:variable. Later changing to the "correct"
behaviour means breaking any stylesheets that expected the older behaviour. In
turn that means such users will experience some pain in migrating, or you'll
need to introduce backwards compatibility options to be able to select between
the two behaviours.
You asked earlier, "Is there an escalation strategy at Xalan...who makes the
final calls on these things?" The Xalan PMC makes the final call on what gets
into a release, and also has the authority to reject any contribution (by a 75%
majority vote of the PMC). For ordinary contributions that aren't being
considered for an actual release, all you need to do is convince a committer to
commit your change - which you're admittedly finding to be a very high hurdle.
In any event, I was thinking - before I saw your post about forking the code -
that the right way forward might be to create a branch and add your
contribution there. Then people can extract and build the code, play with it,
make further contributions to address the concerns. After that, we could fold
it back onto the main trunk. Let me know how you feel about that suggestion.
Thanks
> Ability to set non tree fragment variable using an extension element (PATCH
> SUPPLIED)
> -------------------------------------------------------------------------------------
>
> Key: XALANJ-2510
> URL: https://issues.apache.org/jira/browse/XALANJ-2510
> Project: XalanJ2
> Issue Type: Improvement
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: Xalan-extensions
> Affects Versions: The Latest Development Code
> Reporter: Adam Jenkins
> Fix For: The Latest Development Code
>
> Attachments: XALANJ-2510.patch
>
>
> When using extension elements, there is no way to set a non XRTreeFrag
> related variable.
> For example, say you have:
> <xsl:variable name="myvar">
> <my:extension someAttribute="somevalue"/>
> </xsl:variable>
> If my:extension wants to set a tree fragment, string or nodeset into myvar,
> that's not a problem, however if it wants to set a java object, currently
> there is no mechanism for that (any java object passed either returned from
> the method or passed to XSLProcessorContext.outputToResultTree is
> toString()'ed before being passed back to the ElemVariable.getValue() method).
> The proposed change (patch supplied) is to supply an optional variable on
> ElemVariable.java whereby child extension elements can call up to their
> parent and set an XPath to be evaluated after the extension element has
> finished processing.
> This requires only very minor modification to the ElemVariable.getValue
> method to check this variable.
> This also ensures that this is optional functionality and will not affect
> that basic Xalan processing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscr...@xml.apache.org
For additional commands, e-mail: xalan-dev-h...@xml.apache.org
