[jira] [Resolved] (XALANJ-2656) implementation of xslt xsl:attribute element's "select" attribute, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi resolved XALANJ-2656.
--
Resolution: Fixed

I'm marking this issue as resolved, since the xalanj codebase changes for this 
have been committed to the xalan-java repos on the branch xalan-j_xslt3.0.

> implementation of xslt xsl:attribute element's "select" attribute, for xalanj 
> interpretive processor
> 
>
> Key: XALANJ-2656
> URL: https://issues.apache.org/jira/browse/XALANJ-2656
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: Xalan-interpretive
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: xsl_attribute_test_files.zip
>
>
> I'm creating this jira issue, to track specific enhancements to XSLT 
> xsl:attribute element implementation by xalanj.
> XSLT 1.0 didn't allow xsl:attribute element to have an "select" attribute. 
> But XSLT 3.0 allows this.
> The XSLT 3.0 spec, says following (among other things) about xsl:attribute 
> element,
> "The string value of the new attribute node may be defined either by using 
> the select attribute, or by the sequence constructor that forms the content 
> of the xsl:attribute element. These are mutually exclusive: if the select 
> attribute is present then the sequence constructor must be empty, and if the 
> sequence constructor is non-empty then the select attribute must be absent."
> I've modified the xalanj codebase a bit (on xalan-java repos's branch 
> xalan-j_xslt3.0), to implement xsl:attribute element to have an "select" 
> attribute (in addition to, xsl:attribute element to have child contents which 
> was already implemented by xalanj).
> Few working test cases, for this jira issue have been attached as zip archive.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2656) implementation of xslt xsl:attribute element's "select" attribute, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2656:
-
Description: 
I'm creating this jira issue, to track specific enhancements to XSLT 
xsl:attribute element implementation by xalanj.

XSLT 1.0 didn't allow xsl:attribute element to have an "select" attribute. But 
XSLT 3.0 allows this.

The XSLT 3.0 spec, says following (among other things) about xsl:attribute 
element,

"The string value of the new attribute node may be defined either by using the 
select attribute, or by the sequence constructor that forms the content of the 
xsl:attribute element. These are mutually exclusive: if the select attribute is 
present then the sequence constructor must be empty, and if the sequence 
constructor is non-empty then the select attribute must be absent."

I've modified the xalanj codebase a bit (on xalan-java repos's branch 
xalan-j_xslt3.0), to implement xsl:attribute element to have an "select" 
attribute (in addition to, xsl:attribute element to have child contents which 
was already implemented by xalanj).

Few working test cases, for this jira issue have been attached as zip archive.

  was:
I'm creating this jira issue, to track specific enhancements to XSLT 
xsl:attribute element implementation by xalanj.

XSLT 1.0 didn't allow xsl:attribute element to have an "select" attribute. But 
XSLT 3.0 allows this.

The XSLT 3.0 spec, says following (among other things) about xsl:attribute 
element,

"The string value of the new attribute node may be defined either by using the 
select attribute, or by the sequence constructor that forms the content of the 
xsl:attribute element. These are mutually exclusive: if the select attribute is 
present then the sequence constructor must be empty, and if the sequence 
constructor is non-empty then the select attribute must be absent."

I've modified the xalanj codebase a bit (on xalan-java repos's branch 
xalan-j_xslt3.0), to implement xsl:attribute element to have an "select" 
attribute (in addition to, xsl:attribute element to have child contents which 
was already implemented by xalanj).


> implementation of xslt xsl:attribute element's "select" attribute, for xalanj 
> interpretive processor
> 
>
> Key: XALANJ-2656
> URL: https://issues.apache.org/jira/browse/XALANJ-2656
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: Xalan-interpretive
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: xsl_attribute_test_files.zip
>
>
> I'm creating this jira issue, to track specific enhancements to XSLT 
> xsl:attribute element implementation by xalanj.
> XSLT 1.0 didn't allow xsl:attribute element to have an "select" attribute. 
> But XSLT 3.0 allows this.
> The XSLT 3.0 spec, says following (among other things) about xsl:attribute 
> element,
> "The string value of the new attribute node may be defined either by using 
> the select attribute, or by the sequence constructor that forms the content 
> of the xsl:attribute element. These are mutually exclusive: if the select 
> attribute is present then the sequence constructor must be empty, and if the 
> sequence constructor is non-empty then the select attribute must be absent."
> I've modified the xalanj codebase a bit (on xalan-java repos's branch 
> xalan-j_xslt3.0), to implement xsl:attribute element to have an "select" 
> attribute (in addition to, xsl:attribute element to have child contents which 
> was already implemented by xalanj).
> Few working test cases, for this jira issue have been attached as zip archive.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2656) implementation of xslt xsl:attribute element's "select" attribute, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2656:
-
Attachment: xsl_attribute_test_files.zip

> implementation of xslt xsl:attribute element's "select" attribute, for xalanj 
> interpretive processor
> 
>
> Key: XALANJ-2656
> URL: https://issues.apache.org/jira/browse/XALANJ-2656
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: Xalan-interpretive
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: xsl_attribute_test_files.zip
>
>
> I'm creating this jira issue, to track specific enhancements to XSLT 
> xsl:attribute element implementation by xalanj.
> XSLT 1.0 didn't allow xsl:attribute element to have an "select" attribute. 
> But XSLT 3.0 allows this.
> The XSLT 3.0 spec, says following (among other things) about xsl:attribute 
> element,
> "The string value of the new attribute node may be defined either by using 
> the select attribute, or by the sequence constructor that forms the content 
> of the xsl:attribute element. These are mutually exclusive: if the select 
> attribute is present then the sequence constructor must be empty, and if the 
> sequence constructor is non-empty then the select attribute must be absent."
> I've modified the xalanj codebase a bit (on xalan-java repos's branch 
> xalan-j_xslt3.0), to implement xsl:attribute element to have an "select" 
> attribute (in addition to, xsl:attribute element to have child contents which 
> was already implemented by xalanj).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANJ-2656) implementation of xslt xsl:attribute element's "select" attribute, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

Mukul Gandhi created XALANJ-2656:


 Summary: implementation of xslt xsl:attribute element's "select" 
attribute, for xalanj interpretive processor
 Key: XALANJ-2656
 URL: https://issues.apache.org/jira/browse/XALANJ-2656
 Project: XalanJ2
  Issue Type: New Feature
  Security Level: No security risk; visible to anyone (Ordinary problems in 
Xalan projects.  Anybody can view the issue.)
  Components: Xalan-interpretive
Reporter: Mukul Gandhi
Assignee: Mukul Gandhi


I'm creating this jira issue, to track specific enhancements to XSLT 
xsl:attribute element implementation by xalanj.

XSLT 1.0 didn't allow xsl:attribute element to have an "select" attribute. But 
XSLT 3.0 allows this.

The XSLT 3.0 spec, says following (among other things) about xsl:attribute 
element,

"The string value of the new attribute node may be defined either by using the 
select attribute, or by the sequence constructor that forms the content of the 
xsl:attribute element. These are mutually exclusive: if the select attribute is 
present then the sequence constructor must be empty, and if the sequence 
constructor is non-empty then the select attribute must be absent."

I've modified the xalanj codebase a bit (on xalan-java repos's branch 
xalan-j_xslt3.0), to implement xsl:attribute element to have an "select" 
attribute (in addition to, xsl:attribute element to have child contents which 
was already implemented by xalanj).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2655) implementation of xpath 3.1 fn:abs() function, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2655:
-
Attachment: test1.xsl

> implementation of xpath 3.1 fn:abs() function, for xalanj interpretive 
> processor
> 
>
> Key: XALANJ-2655
> URL: https://issues.apache.org/jira/browse/XALANJ-2655
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: Xalan-interpretive, XPath-function
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: test1.xsl, test1_a.xml
>
>
> I'm creating this jira issue, to track implementation of XPath 3.1 fn:abs() 
> function.
>  
> I've committed an implementation for this, to xalan-java repos's branch 
> xalan-j_xslt3.0.
> A working test case, for this jira issue has been attached.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2655) implementation of xpath 3.1 fn:abs() function, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2655:
-
Attachment: (was: test1.xsl)

> implementation of xpath 3.1 fn:abs() function, for xalanj interpretive 
> processor
> 
>
> Key: XALANJ-2655
> URL: https://issues.apache.org/jira/browse/XALANJ-2655
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: Xalan-interpretive, XPath-function
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: test1_a.xml
>
>
> I'm creating this jira issue, to track implementation of XPath 3.1 fn:abs() 
> function.
>  
> I've committed an implementation for this, to xalan-java repos's branch 
> xalan-j_xslt3.0.
> A working test case, for this jira issue has been attached.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-2603) Xalan 2.7.1

[Joe Kesselman (Jira)]

[ 
https://issues.apache.org/jira/browse/XALANJ-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722424#comment-17722424
 ] 

Joe Kesselman commented on XALANJ-2603:
---

In the absence of any response with specifics since 2016, move to close.

> Xalan 2.7.1
> ---
>
> Key: XALANJ-2603
> URL: https://issues.apache.org/jira/browse/XALANJ-2603
> Project: XalanJ2
>  Issue Type: Bug
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: Xalan
>Affects Versions: 2.7.1
>Reporter: HITESH MEHRA
>Assignee: Steven J. Hathaway
>Priority: Major
>
> Hi Team,
> We were using the Xalan 2.7.1 in our Java application which was deployed in 
> Solaris with JDK 1.7, 32 bit. The XSL were also compiled in JDK 1.7, 32 bit.
> We are parsing our XML and using the node() function in some conditions like 
> below:
> [descendant::node() != ''] 
> But we recently moved our application to CentOS with JDK 1.8 64 bit. The XSL 
> were compiled in JDK 1.8, 64 bit. After this migration/upgrade in production 
> , we are now having issues with the above condition (yes, we missed to test 
> this corner scenario in QA environment) . The above condition is always 
> returning false.
> And due to this, our XML is not getting properly parsed.
> Do we know if this feature is OS/JDK dependent.
> Any pointers will be extremely helpful.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-1546) XSLTC: top-level xsl:variable with document() breaks

[Joe Kesselman (Jira)]

[ 
https://issues.apache.org/jira/browse/XALANJ-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722423#comment-17722423
 ] 

Joe Kesselman commented on XALANJ-1546:
---

Given no response since '07, and the inability to reproduce it with Xalan 2.7.0 
at that date, move to close this as fixed.

> XSLTC: top-level xsl:variable with document() breaks
> 
>
> Key: XALANJ-1546
> URL: https://issues.apache.org/jira/browse/XALANJ-1546
> Project: XalanJ2
>  Issue Type: Bug
>  Components: XSLTC
>Affects Versions: 2.5
> Environment: Operating System: Linux
> Platform: Other
>Reporter: Jeff Turner
>Priority: Major
> Attachments: ASF.LICENSE.NOT.GRANTED--DocumentTest.java, 
> ASF.LICENSE.NOT.GRANTED--document.xml, ASF.LICENSE.NOT.GRANTED--other.xml, 
> ASF.LICENSE.NOT.GRANTED--stylesheet.xsl, 
> ASF.LICENSE.NOT.GRANTED--xsltcbug2.tgz, XALANJ-1546.patch, 
> xalan-bug20381-usecase.zip
>
>
> Hi,
> Seems that XSLTC doesn't like using document() in a top-level element:
> 
> This has the effect of *importing* skinconf.xml nodes. If I then have a
> copy-across rule:
>   
> 
>   
>   
> 
>   
> Then skinconf.xml element bodies appear in the output.
> This bug does not show when using regular Xalan, nor does it show up when 
> using
> XSLTC from the command-line. It seems to have something to do with the
> document() function.
> Attached is a sample subsitemap which demonstrates the bug. It can be unpacked
> directly into build/webapp/. A script for testing command-line XSLTC is also
> provided.
> --Jeff



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-2627) Adding multiple transform using addTransform consumes huge memory and cause OOM

[Joe Kesselman (Jira)]

[ 
https://issues.apache.org/jira/browse/XALANJ-2627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722422#comment-17722422
 ] 

Joe Kesselman commented on XALANJ-2627:
---

It's been a long time since I looked at the code, but I would guess that this 
is because running them in cascade is pipelining them, meaning intermediate 
document models must be built and retained until transformation ends. Running 
them sequentially would use only with one input document model at a time, 
discarding it before moving to the next transformation.

That can be confirmed/refuted by pulling a heap dump and looking at what 
objects are consuming the additional storage (as well as by grovelling through 
the code in a debugger).

There may be space versus speed trade-offs here.

> Adding multiple transform using addTransform consumes huge memory and cause 
> OOM
> ---
>
> Key: XALANJ-2627
> URL: https://issues.apache.org/jira/browse/XALANJ-2627
> Project: XalanJ2
>  Issue Type: Bug
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>Reporter: Subhajit
>Assignee: Gary D. Gregory
>Priority: Major
>
> We are using XALAN for XSLT transformation. We have around 10 transformer. 
> Our pattern is
>  
> Transformation.builder(transformationFactory)
> .setUseInterpreter(true)
> .setLogger(log)
> .setSource(some source))
> .setResult(some target)
> .addTransform(Handler1())
> .addTransform(Handler2())
> .addTransform(Handler3())
> .addTransform(Handler4())
> .addTransform(Handler5())
> .addTransform(Handler6())
> .addTransform(Handler7())
> .addTransform(Handler8())
> .addTransform(Handler9())
> .addTransform(Handler10())
> .addTransform(Handler11())
> .addTransform(Handler12())
> .build()
> .transform();
>  
> This pattern seems to take lots of memory. But if  we do them individually 12 
> times (by using output of 1 as input of another), memory usage get reduced.
>  
> Transformation.builder(transformationFactory)
> .setUseInterpreter(true)
> .setLogger(log)
> .setSource(some source))
> .setResult(some target)
> .addTransform(Handler1())
> .build()
> .transform();
>  
> It seems Xalan is holding unnecessary memory for the 1st type of pattern
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-2628) Remove synchornization on primitive classes

[Joe Kesselman (Jira)]

[ 
https://issues.apache.org/jira/browse/XALANJ-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722421#comment-17722421
 ] 

Joe Kesselman commented on XALANJ-2628:
---

Xalan is still being compiled for compatibility with Java 8, so classes 
deprecated since then may still be needed if a Java 8 replacement doesn't exist.

Are there any alternatives you'd like to suggest?

> Remove synchornization on primitive classes
> ---
>
> Key: XALANJ-2628
> URL: https://issues.apache.org/jira/browse/XALANJ-2628
> Project: XalanJ2
>  Issue Type: Bug
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>Reporter: Thiago Henrique Hupner
>Assignee: Gary D. Gregory
>Priority: Major
>
> JDK 16 marked the primitive class wrappers as deprecated for removal.
> And in the JEP, they also said that would be added a flag to see if there is 
> any synchronization on them.
> [https://openjdk.java.net/jeps/390]
>  
> However, Xalan Serializer 2.7.2 does it in the 
> org.apache.xml.serializer.OutputPropertiesFactory, using the `Integer 
> m_synch_object` field



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-2631) Typo in Javadocs: sting instead of string

[Joe Kesselman (Jira)]

[ 
https://issues.apache.org/jira/browse/XALANJ-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722420#comment-17722420
 ] 

Joe Kesselman commented on XALANJ-2631:
---

Hey, someone actually reads the docs?!

Harmless but embarassing. Yes, should be fixed next time we have the patient on 
the table.

> Typo in Javadocs: sting instead of string
> -
>
> Key: XALANJ-2631
> URL: https://issues.apache.org/jira/browse/XALANJ-2631
> Project: XalanJ2
>  Issue Type: Bug
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>Reporter: Daniel Jelinski
>Assignee: Gary D. Gregory
>Priority: Trivial
>
> Noticed in 2 places:
>  * StringVector 
> [http://svn.apache.org/viewvc/xalan/java/trunk/src/org/apache/xml/utils/StringVector.java?view=markup#l92]
>  * DomHelper 
> [http://svn.apache.org/viewvc/xalan/java/trunk/src/org/apache/xml/utils/DOMHelper.java?view=markup#l496]
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-2633) Where be xalan java codes? and where to create pr to?

[Joe Kesselman (Jira)]

[ 
https://issues.apache.org/jira/browse/XALANJ-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722419#comment-17722419
 ] 

Joe Kesselman commented on XALANJ-2633:
---

[https://github.com/apache/xalan-java] is the one which is currently being 
maintained.

Is there any reason not to close the other?

> Where be xalan java codes? and where to create pr to?
> -
>
> Key: XALANJ-2633
> URL: https://issues.apache.org/jira/browse/XALANJ-2633
> Project: XalanJ2
>  Issue Type: Wish
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>Reporter: Jin Xu
>Assignee: Gary D. Gregory
>Priority: Minor
>
> https://github.com/apache/xalan-java
> or
> https://github.com/apache/xalan-j
> ?
> why there be 2 same repos？



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-2635) Remove JLex.jar from the source repository

[Joe Kesselman (Jira)]

[ 
https://issues.apache.org/jira/browse/XALANJ-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722416#comment-17722416
 ] 

Joe Kesselman commented on XALANJ-2635:
---

JLex.jar's manifest says it was created by Sun Microsystems. A scan of the 
classes finds no other informative strings. 

There was a JLex lexical analyzer generator developed by Elliot Berk at 
Princeton University. It's possible that this is the same code, or a fork of 
it.  We could try comparing them.

I believe this jarfile is indeed a Java implementation of the lex tool.  If 
it's really just lex rather than an enhanced version, we might be able to 
retrofit any other open-source implementation.

> Remove JLex.jar from the source repository
> --
>
> Key: XALANJ-2635
> URL: https://issues.apache.org/jira/browse/XALANJ-2635
> Project: XalanJ2
>  Issue Type: Task
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: XSLTC
>Reporter: Vladimir Sitnikov
>Assignee: Gary D. Gregory
>Priority: Major
>
> https://github.com/apache/xalan-java/tree/master/tools contains JLex.jar 
> which is a binary file, and its provenance is unknown.
> The ASF rules forbid compiled including compiled code to the source 
> repository (see 
> https://lists.apache.org/thread/otx07h6vbjrsqd9r9sqpcpjscvjwtmfc), and in 
> this case, there's no real need to have JLex.jar in the source repository.
> At the same time, the generated 
> {{xalan-java/src/org/apache/xalan/xsltc/compiler/XPathLexer.java}} should be 
> removed from the source control.
> I suggest that JLex.jar should be removed and it should be replaced with 
> something else.
> For instance, the source code of JLex could be added as a separate subfolder, 
> and xalan could compile JLex from sources.
> It looks like the official distribution is not maintained: 
> https://www.cs.princeton.edu/~appel/modern/java/JLex/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] (XALANJ-1324) XSLTC compiltation error : Branch target offset too large for short

[Joe Kesselman (Jira)]

[ https://issues.apache.org/jira/browse/XALANJ-1324 ]


Joe Kesselman deleted comment on XALANJ-1324:
---

was (Author: JIRAUSER285361):
Reported resolved in 2008. Can we close it?

> XSLTC compiltation error : Branch target offset too large for short
> ---
>
> Key: XALANJ-1324
> URL: https://issues.apache.org/jira/browse/XALANJ-1324
> Project: XalanJ2
>  Issue Type: Bug
>  Components: XSLTC
>Affects Versions: 2.7
> Environment: Operating System: Solaris
> Platform: Sun
>Reporter: R Sumathi
>Assignee: Henry Zongaro
>Priority: Blocker
> Fix For: 2.7.1
>
> Attachments: ASF.LICENSE.NOT.GRANTED--Satelindo-SS.xsl, 
> ASF.LICENSE.NOT.GRANTED--Satelindo-SS.xsl, 
> ASF.LICENSE.NOT.GRANTED--transform.java, j1324.patch.txt
>
>
> When I am trying to compile a complex style sheet, I am getting the following 
> error.
> Compiler error(s):
>   Branch target offset too large for short
> Without changing the XSL how to compile it?
> Is there any solution for this?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-1324) XSLTC compiltation error : Branch target offset too large for short

[Joe Kesselman (Jira)]

[ 
https://issues.apache.org/jira/browse/XALANJ-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722413#comment-17722413
 ] 

Joe Kesselman commented on XALANJ-1324:
---

Never mind; I searched on unresolved resolution rather than checking the status 
for RESOLVED or CLOSED. Theoretically the latter should imply the former, but 
it doesn't always. 

> XSLTC compiltation error : Branch target offset too large for short
> ---
>
> Key: XALANJ-1324
> URL: https://issues.apache.org/jira/browse/XALANJ-1324
> Project: XalanJ2
>  Issue Type: Bug
>  Components: XSLTC
>Affects Versions: 2.7
> Environment: Operating System: Solaris
> Platform: Sun
>Reporter: R Sumathi
>Assignee: Henry Zongaro
>Priority: Blocker
> Fix For: 2.7.1
>
> Attachments: ASF.LICENSE.NOT.GRANTED--Satelindo-SS.xsl, 
> ASF.LICENSE.NOT.GRANTED--Satelindo-SS.xsl, 
> ASF.LICENSE.NOT.GRANTED--transform.java, j1324.patch.txt
>
>
> When I am trying to compile a complex style sheet, I am getting the following 
> error.
> Compiler error(s):
>   Branch target offset too large for short
> Without changing the XSL how to compile it?
> Is there any solution for this?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-1810) last() breaks nodeset position

[Joe Kesselman (Jira)]

[ 
https://issues.apache.org/jira/browse/XALANJ-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722412#comment-17722412
 ] 

Joe Kesselman commented on XALANJ-1810:
---

Never mind; I searched on unresolved resolution rather than checking the status 
for RESOLVED or CLOSED. Theoretically the latter should imply the former, but 
it doesn't always.

> last() breaks nodeset position
> --
>
> Key: XALANJ-1810
> URL: https://issues.apache.org/jira/browse/XALANJ-1810
> Project: XalanJ2
>  Issue Type: Bug
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: XPath
>Affects Versions: 2.7.1
> Environment: Operating System: Other
> Platform: Other
>Reporter: Martin Algesten
>Priority: Blocker
> Fix For: 2.7
>
> Attachments: ASF.LICENSE.NOT.GRANTED--Bug27429UnionPathIterator.txt, 
> ASF.LICENSE.NOT.GRANTED--xalancheck.jsp
>
>
> This might be a dupe of #22949, but I'm not sure.
> My XML is:
>   
> 
>   
>   
> 
>   
> My transform does a:
>   
> ...
>   
>  - 
>   
> The 'last()' call seems to upset the current position in the nodeset and only 
> the first section will match.
> Will attach my test JSTL transform.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-1810) last() breaks nodeset position

[Joe Kesselman (Jira)]

[ 
https://issues.apache.org/jira/browse/XALANJ-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722411#comment-17722411
 ] 

Joe Kesselman commented on XALANJ-1810:
---

It's been over a decade. Mark resolved?

> last() breaks nodeset position
> --
>
> Key: XALANJ-1810
> URL: https://issues.apache.org/jira/browse/XALANJ-1810
> Project: XalanJ2
>  Issue Type: Bug
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: XPath
>Affects Versions: 2.7.1
> Environment: Operating System: Other
> Platform: Other
>Reporter: Martin Algesten
>Priority: Blocker
> Fix For: 2.7
>
> Attachments: ASF.LICENSE.NOT.GRANTED--Bug27429UnionPathIterator.txt, 
> ASF.LICENSE.NOT.GRANTED--xalancheck.jsp
>
>
> This might be a dupe of #22949, but I'm not sure.
> My XML is:
>   
> 
>   
>   
> 
>   
> My transform does a:
>   
> ...
>   
>  - 
>   
> The 'last()' call seems to upset the current position in the nodeset and only 
> the first section will match.
> Will attach my test JSTL transform.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-1324) XSLTC compiltation error : Branch target offset too large for short

[Joe Kesselman (Jira)]

[ 
https://issues.apache.org/jira/browse/XALANJ-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722410#comment-17722410
 ] 

Joe Kesselman commented on XALANJ-1324:
---

Reported resolved in 2008. Can we close it?

> XSLTC compiltation error : Branch target offset too large for short
> ---
>
> Key: XALANJ-1324
> URL: https://issues.apache.org/jira/browse/XALANJ-1324
> Project: XalanJ2
>  Issue Type: Bug
>  Components: XSLTC
>Affects Versions: 2.7
> Environment: Operating System: Solaris
> Platform: Sun
>Reporter: R Sumathi
>Assignee: Henry Zongaro
>Priority: Blocker
> Fix For: 2.7.1
>
> Attachments: ASF.LICENSE.NOT.GRANTED--Satelindo-SS.xsl, 
> ASF.LICENSE.NOT.GRANTED--Satelindo-SS.xsl, 
> ASF.LICENSE.NOT.GRANTED--transform.java, j1324.patch.txt
>
>
> When I am trying to compile a complex style sheet, I am getting the following 
> error.
> Compiler error(s):
>   Branch target offset too large for short
> Without changing the XSL how to compile it?
> Is there any solution for this?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-2385) hi need a great help please post me :)

[Joe Kesselman (Jira)]

[ 
https://issues.apache.org/jira/browse/XALANJ-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722409#comment-17722409
 ] 

Joe Kesselman commented on XALANJ-2385:
---

Given the age of this (and the fact that it doesn't actually seem to be a bug 
report or feature request), can we close it?

> hi need a great help please post me :)
> --
>
> Key: XALANJ-2385
> URL: https://issues.apache.org/jira/browse/XALANJ-2385
> Project: XalanJ2
>  Issue Type: Bug
>  Components: Xalan
>Affects Versions: 2.7
> Environment: Unix 
> Solaris 
>Reporter: mirko
>Priority: Blocker
>
> Good morning
> i have 1 great problem whit stykesheet.
> I trasmormed 1 xsl in 1 class java whit xalan
> and now i need use this class in other my class for create 1 fop Document.
> Not found what class i need and what source i need use for this 
> implementation.
> Any one write in this post a little code to example me?
> my code in this moment is this!!!
> ehre i modified my code for use a class and not a file?
> pls help not understend where is the point and class
> tanks 
>File xmlfile = new 
> File("webapps"+req.getContextPath()+fileSeparator+"data"+fileSeparator,xmlNames[0]);
>   File xsltfile = new 
> File("webapps"+req.getContextPath()+fileSeparator+"xslfo"+fileSeparator,xsltNames[0]);
>   
>   String baseUrl = 
> "http://"+req.getServerName()+req.getContextPath()+fileSeparator+"xslfo";
>   // setup canale uscita 
> 
>   ByteArrayOutputStream outi = new ByteArrayOutputStream();
>   
>   try {
> 
> 
>   // configurare fopFactory 
>   FopFactory fopFactory = FopFactory.newInstance();
>   
>   DefaultConfigurationBuilder build = new 
> DefaultConfigurationBuilder();
>   Configuration config = build.buildFromFile(new 
> File("/usr/local/fop/conf/fopConfig.xml"));
>   fopFactory.setUserConfig(config);
>   
>   // configurare foUserAgent 
> 
>   FOUserAgent foUserAgent = fopFactory.newFOUserAgent();
>   foUserAgent.setBaseURL(baseUrl);
>   
>   // carichiamo la fop
> Fop fop = fopFactory.newFop(MimeConstants.MIME_PDF, 
> foUserAgent, outi);
> 
> // carichiamo il file di conversione xslt
> TransformerFactory factory = TransformerFactory.newInstance();
> Transformer transformer = factory.newTransformer(new 
> StreamSource(xsltfile));
>   
> // valori nello stylesheet
> transformer.setParameter("versionParam", "2.0");
> 
> // carichiamo i dati del file
> Source src = new StreamSource(xmlfile);
> 
> // creiamo l'oggetto sax utilizzato per la conversione con i 
> parametri definiti dal fop per acrobat
> Result res = new SAXResult(fop.getDefaultHandler());
> 
> // converto i dati
> transformer.transform(src, res);
> }



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[GitHub] [xalan-test] jkesselm commented on pull request #1: Move tests/2.7.3 into main test driver framework, document bugzilla test status

[via GitHub]

jkesselm commented on PR #1:
URL: https://github.com/apache/xalan-test/pull/1#issuecomment-1546730860

   Thank ye kindly, sir.  I'll look at fixing the two reproduced issues.
   
   Worth discussing what we do with the other tests, or should I just submit a 
proposal?
   
   --
  /_  Joe Kesselman (he/him/his)
   -/ _) My Alexa skill for New Music/New Sounds fans:
  /   https://www.amazon.com/dp/B09WJ3H657/
   
   () Plaintext Ribbon Campaign
   /\ Stamp out HTML mail!
   
   From: Gary Gregory ***@***.***>
   Sent: Saturday, May 13, 2023 12:46:12 PM
   To: apache/xalan-test ***@***.***>
   Cc: Joe Kesselman ***@***.***>; Mention ***@***.***>
   Subject: Re: [apache/xalan-test] Move tests/2.7.3 into main test driver 
framework, document bugzilla test status (PR #1)
   
   
   Merged #1 into master.
   
   —
   Reply to this email directly, view it on 
GitHub, or 
unsubscribe.
   You are receiving this because you were mentioned.Message ID: ***@***.***>
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[GitHub] [xalan-test] garydgregory merged pull request #1: Move tests/2.7.3 into main test driver framework, document bugzilla test status

[via GitHub]

garydgregory merged PR #1:
URL: https://github.com/apache/xalan-test/pull/1


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[GitHub] [xalan-test] jkesselm commented on pull request #1: Move tests/2.7.3 into main test driver framework, document bugzilla test status

[via GitHub]

jkesselm commented on PR #1:
URL: https://github.com/apache/xalan-test/pull/1#issuecomment-1546700059

   Squash, by all means.
   
   Valid point re tooling configs and code style.
   
   --
  /_  Joe Kesselman (he/him/his)
   -/ _) My Alexa skill for New Music/New Sounds fans:
  /   https://www.amazon.com/dp/B09WJ3H657/
   
   () Plaintext Ribbon Campaign
   /\ Stamp out HTML mail!
   
   From: Gary Gregory ***@***.***>
   Sent: Saturday, May 13, 2023 11:30:43 AM
   To: apache/xalan-test ***@***.***>
   Cc: Joe Kesselman ***@***.***>; Mention ***@***.***>
   Subject: Re: [apache/xalan-test] Move tests/2.7.3 into main test driver 
framework, document bugzilla test status (PR #1)
   
   
   @garydgregory commented on this pull request.
   
   @jkesselm and all:
   Do you care about the commit history or can I squash & commit? I generally 
squash PRs assuming that the commits are WIP (unless I hear otherwise).
   I would prefer we NOT store Eclipse, IntelliJ, and assorted editor 
configuration files. It is too painful to sync; instead we should, IMO: Migrate 
to Maven and enforce style with the Maven Checkstyle plugin or use the Spotless 
plugin in addition to PMD and SpotBugs.
   
   —
   Reply to this email directly, view it on 
GitHub,
 or 
unsubscribe.
   You are receiving this because you were mentioned.Message ID: ***@***.***>
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-2649) Xalan 2.7.3 is missing dependencies (Regression from 2.7.2)

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/XALANJ-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722376#comment-17722376
 ] 

Gary D. Gregory commented on XALANJ-2649:
-

"I don't know what changed to omit the dependencies in 2.7.2"

Nothing changed because there is and was zero dependency management since we 
use neither Ivy nor Maven. For 2.7.2, I probably created a POM file by hand and 
did not put it in the repo to avoid confusion with Ant. For 2.7.3, I used the 
simplest Maven deploy command, which was already a pain and also required 
downloading files post-deploy to sign them before even being able to close the 
Nexus repo. If and when we move to Maven, you get all of that for free.

> Xalan 2.7.3 is missing dependencies (Regression from 2.7.2)
> ---
>
> Key: XALANJ-2649
> URL: https://issues.apache.org/jira/browse/XALANJ-2649
> Project: XalanJ2
>  Issue Type: Bug
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: Build, Xalan
>Affects Versions: 2.7.3
>Reporter: mt
>Assignee: Gary D. Gregory
>Priority: Major
> Attachments: serializer-2.7.3.pom, xalan-2.7.3.pom
>
>
> After upgrading from 2.7.2 to 2.7.3 via maven central, we get the following 
> runtime error.
> It seems like 2.7.3 is missing the dependencies to serializer and xercesImpl 
> . After manually adding a dependency to serializer:2.7.3 , the issue is fixed.
> This can also be seen in Maven Central:
> [Maven Central: xalan:xalan:2.7.2 
> (sonatype.com)|https://central.sonatype.com/artifact/xalan/xalan/2.7.2/dependencies]
>  -> has dependencies on serializer and xercesImpl
> [Maven Central: xalan:xalan:2.7.3 
> (sonatype.com)|https://central.sonatype.com/artifact/xalan/xalan/2.7.3/dependencies]
>  -> no dependencies
>  
> {code:java}
> java.lang.NoClassDefFoundError: org/apache/xml/serializer/SerializerTrace
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1012)
> at 
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
> at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
> at 
> org.apache.xalan.processor.ProcessorStylesheetElement.getStylesheetRoot(ProcessorStylesheetElement.java:123)
> at 
> org.apache.xalan.processor.ProcessorStylesheetElement.startElement(ProcessorStylesheetElement.java:74)
> at 
> org.apache.xalan.processor.StylesheetHandler.startElement(StylesheetHandler.java:623)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:518)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:374)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook(XMLNSDocumentScannerImpl.java:613)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:3079)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:836)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:542)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:889)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:825)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1224)
> at

[jira] [Resolved] (XALANJ-2655) implementation of xpath 3.1 fn:abs() function, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi resolved XALANJ-2655.
--
Resolution: Fixed

I'm marking this issue as resolved, since the xalanj codebase changes for this 
have been committed to the xalan-java repos on the branch xalan-j_xslt3.0.

> implementation of xpath 3.1 fn:abs() function, for xalanj interpretive 
> processor
> 
>
> Key: XALANJ-2655
> URL: https://issues.apache.org/jira/browse/XALANJ-2655
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: Xalan-interpretive, XPath-function
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: test1.xsl, test1_a.xml
>
>
> I'm creating this jira issue, to track implementation of XPath 3.1 fn:abs() 
> function.
>  
> I've committed an implementation for this, to xalan-java repos's branch 
> xalan-j_xslt3.0.
> A working test case, for this jira issue has been attached.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2655) implementation of xpath 3.1 fn:abs() function, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2655:
-
Description: 
I'm creating this jira issue, to track implementation of XPath 3.1 fn:abs() 
function.
 
I've committed an implementation for this, to xalan-java repos's branch 
xalan-j_xslt3.0.

A working test case, for this jira issue has been attached.

  was:
I'm creating this jira issue, to track implementation of XPath 3.1 fn:abs() 
function.
 
I've committed an implementation for this, to xalan-java repos's branch 
xalan-j_xslt3.0.


> implementation of xpath 3.1 fn:abs() function, for xalanj interpretive 
> processor
> 
>
> Key: XALANJ-2655
> URL: https://issues.apache.org/jira/browse/XALANJ-2655
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: Xalan-interpretive, XPath-function
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: test1.xsl, test1_a.xml
>
>
> I'm creating this jira issue, to track implementation of XPath 3.1 fn:abs() 
> function.
>  
> I've committed an implementation for this, to xalan-java repos's branch 
> xalan-j_xslt3.0.
> A working test case, for this jira issue has been attached.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2655) implementation of xpath 3.1 fn:abs() function, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2655:
-
Attachment: test1.xsl
test1_a.xml

> implementation of xpath 3.1 fn:abs() function, for xalanj interpretive 
> processor
> 
>
> Key: XALANJ-2655
> URL: https://issues.apache.org/jira/browse/XALANJ-2655
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: Xalan-interpretive, XPath-function
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: test1.xsl, test1_a.xml
>
>
> I'm creating this jira issue, to track implementation of XPath 3.1 fn:abs() 
> function.
>  
> I've committed an implementation for this, to xalan-java repos's branch 
> xalan-j_xslt3.0.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANJ-2655) implementation of xpath 3.1 fn:abs() function, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

Mukul Gandhi created XALANJ-2655:


 Summary: implementation of xpath 3.1 fn:abs() function, for xalanj 
interpretive processor
 Key: XALANJ-2655
 URL: https://issues.apache.org/jira/browse/XALANJ-2655
 Project: XalanJ2
  Issue Type: New Feature
  Security Level: No security risk; visible to anyone (Ordinary problems in 
Xalan projects.  Anybody can view the issue.)
  Components: Xalan-interpretive, XPath-function
Reporter: Mukul Gandhi
Assignee: Mukul Gandhi


I'm creating this jira issue, to track implementation of XPath 3.1 fn:abs() 
function.
 
I've committed an implementation for this, to xalan-java repos's branch 
xalan-j_xslt3.0.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Resolved] (XALANJ-2654) increasing the default xml document result serialization indent amount, during xslt transformation

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi resolved XALANJ-2654.
--
Resolution: Fixed

I'm marking this issue as resolved, since XalanJ codebase change for this 
issue, has been committed to xalan-java implementation repos.

> increasing the default xml document result serialization indent amount, 
> during xslt transformation
> --
>
> Key: XALANJ-2654
> URL: https://issues.apache.org/jira/browse/XALANJ-2654
> Project: XalanJ2
>  Issue Type: Improvement
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: Serialization, Xalan-interpretive
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Minor
>
> Currently, when an XSLT element is specified as following within the 
> stylesheet,
> 
> XalanJ has a default XML document result indent amount as 0. I've made a 
> minor change to this, XalanJ implementation configuration, and have made this 
> default XML document result indent amount as 2. This makes little bit easier 
> to read visually, the XML document output by XalanJ's XSLT transformer.
> I've made this XalanJ codebase change, to both the branches 'master' and 
> 'xalan-j_xslt3.0' on the repos xalan-java. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANJ-2654) increasing the default xml document result serialization indent amount, during xslt transformation

[Mukul Gandhi (Jira)]

Mukul Gandhi created XALANJ-2654:


 Summary: increasing the default xml document result serialization 
indent amount, during xslt transformation
 Key: XALANJ-2654
 URL: https://issues.apache.org/jira/browse/XALANJ-2654
 Project: XalanJ2
  Issue Type: Improvement
  Security Level: No security risk; visible to anyone (Ordinary problems in 
Xalan projects.  Anybody can view the issue.)
  Components: Serialization, Xalan-interpretive
Reporter: Mukul Gandhi
Assignee: Mukul Gandhi


Currently, when an XSLT element is specified as following within the stylesheet,



XalanJ has a default XML document result indent amount as 0. I've made a minor 
change to this, XalanJ implementation configuration, and have made this default 
XML document result indent amount as 2. This makes little bit easier to read 
visually, the XML document output by XalanJ's XSLT transformer.

I've made this XalanJ codebase change, to both the branches 'master' and 
'xalan-j_xslt3.0' on the repos xalan-java. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2646) Implementation of xslt 3.0's xsl:for-each-group instruction, for XalanJ's interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2646:
-
Attachment: xsl3_for_each_group_test_files.zip

> Implementation of xslt 3.0's xsl:for-each-group instruction, for XalanJ's 
> interpretive processor
> 
>
> Key: XALANJ-2646
> URL: https://issues.apache.org/jira/browse/XALANJ-2646
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: Xalan-interpretive
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: xsl3_for_each_group_test_files.zip
>
>
> I'm creating this jira issue, to track implementation of XSLT 3.0's 
> xsl:for-each-group instruction, for XalanJ's interpretive processor.
> I've done little bit of implementation for this, that seems to work fine for 
> various primary XSLT 3.0 xsl:for-each-group use cases.
> The XSLT 3.0 structural implementation for xsl:for-each-group, implementing 
> the XSLT element xsl:for-each-group, and functions fn:current-group(), 
> fn:current-grouping-key() have been completed. All the xsl:for-each-group's 
> grouping attributes, i.e 'group-by', 'group-adjacent', 'group-starting-with', 
> 'group-ending-with' have been implemented.
> Implementation of using xsl:sort element(s) with xsl:for-each-group element 
> has been fairly completed. The XSLT 3.0 spec, specifies following grammar for 
> xsl:sort element,
> select? = expression
>lang? = { language }
>order? = { "ascending" | "descending" }
>collation? = { uri }
>stable? = { boolean }
>case-order? = { "upper-first" | "lower-first" }
>data-type? = { "text" | "number" | eqname } >
> 
> 
> Except the xsl:sort element's attributes 'collation' and 'stable', all other 
> attributes of xsl:sort element have been implemented to work with 
> xsl:for-each-group element.
> Currently, xsl:for-each-group's grouping keys (i.e, value of xslt 3.0 
> function fn:current-grouping-key() for a group) can have values typed as 
> string, number or boolean (any other XPath typed value for xslt 3.0's 
> grouping keys is converted to a string value).
> The relevant working test cases, for this jira issue have been attached as 
> zip archive to this jira issue.  
> The codebase changes for these mentioned XSLT 3.0 implementation aspects, 
> have been committed to xalan-java repo's branch xalan-j_xslt3.0.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2646) Implementation of xslt 3.0's xsl:for-each-group instruction, for XalanJ's interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2646:
-
Attachment: (was: xsl3_for_each_group_test_files.zip)

> Implementation of xslt 3.0's xsl:for-each-group instruction, for XalanJ's 
> interpretive processor
> 
>
> Key: XALANJ-2646
> URL: https://issues.apache.org/jira/browse/XALANJ-2646
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: Xalan-interpretive
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
>
> I'm creating this jira issue, to track implementation of XSLT 3.0's 
> xsl:for-each-group instruction, for XalanJ's interpretive processor.
> I've done little bit of implementation for this, that seems to work fine for 
> various primary XSLT 3.0 xsl:for-each-group use cases.
> The XSLT 3.0 structural implementation for xsl:for-each-group, implementing 
> the XSLT element xsl:for-each-group, and functions fn:current-group(), 
> fn:current-grouping-key() have been completed. All the xsl:for-each-group's 
> grouping attributes, i.e 'group-by', 'group-adjacent', 'group-starting-with', 
> 'group-ending-with' have been implemented.
> Implementation of using xsl:sort element(s) with xsl:for-each-group element 
> has been fairly completed. The XSLT 3.0 spec, specifies following grammar for 
> xsl:sort element,
> select? = expression
>lang? = { language }
>order? = { "ascending" | "descending" }
>collation? = { uri }
>stable? = { boolean }
>case-order? = { "upper-first" | "lower-first" }
>data-type? = { "text" | "number" | eqname } >
> 
> 
> Except the xsl:sort element's attributes 'collation' and 'stable', all other 
> attributes of xsl:sort element have been implemented to work with 
> xsl:for-each-group element.
> Currently, xsl:for-each-group's grouping keys (i.e, value of xslt 3.0 
> function fn:current-grouping-key() for a group) can have values typed as 
> string, number or boolean (any other XPath typed value for xslt 3.0's 
> grouping keys is converted to a string value).
> The relevant working test cases, for this jira issue have been attached as 
> zip archive to this jira issue.  
> The codebase changes for these mentioned XSLT 3.0 implementation aspects, 
> have been committed to xalan-java repo's branch xalan-j_xslt3.0.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-2649) Xalan 2.7.3 is missing dependencies (Regression from 2.7.2)

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/XALANJ-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722356#comment-17722356
 ] 

Elliotte Rusty Harold commented on XALANJ-2649:
---

The 2.7.3 pom is also missing a lot of other useful metadata that was present 
in 2.7.2:

```
  Xalan Java
  
Xalan-Java is an XSLT processor for transforming XML documents into HTML,
text, or other XML document types. It implements XSL Transformations (XSLT)
Version 1.0 and XML Path Language (XPath) Version 1.0 and can be used from
the command line, in an applet or a servlet, or as a module in other 
program.
  
  http://xml.apache.org/xalan-j/  
```

> Xalan 2.7.3 is missing dependencies (Regression from 2.7.2)
> ---
>
> Key: XALANJ-2649
> URL: https://issues.apache.org/jira/browse/XALANJ-2649
> Project: XalanJ2
>  Issue Type: Bug
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: Build, Xalan
>Affects Versions: 2.7.3
>Reporter: mt
>Assignee: Gary D. Gregory
>Priority: Major
> Attachments: serializer-2.7.3.pom, xalan-2.7.3.pom
>
>
> After upgrading from 2.7.2 to 2.7.3 via maven central, we get the following 
> runtime error.
> It seems like 2.7.3 is missing the dependencies to serializer and xercesImpl 
> . After manually adding a dependency to serializer:2.7.3 , the issue is fixed.
> This can also be seen in Maven Central:
> [Maven Central: xalan:xalan:2.7.2 
> (sonatype.com)|https://central.sonatype.com/artifact/xalan/xalan/2.7.2/dependencies]
>  -> has dependencies on serializer and xercesImpl
> [Maven Central: xalan:xalan:2.7.3 
> (sonatype.com)|https://central.sonatype.com/artifact/xalan/xalan/2.7.3/dependencies]
>  -> no dependencies
>  
> {code:java}
> java.lang.NoClassDefFoundError: org/apache/xml/serializer/SerializerTrace
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1012)
> at 
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
> at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
> at 
> org.apache.xalan.processor.ProcessorStylesheetElement.getStylesheetRoot(ProcessorStylesheetElement.java:123)
> at 
> org.apache.xalan.processor.ProcessorStylesheetElement.startElement(ProcessorStylesheetElement.java:74)
> at 
> org.apache.xalan.processor.StylesheetHandler.startElement(StylesheetHandler.java:623)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:518)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:374)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook(XMLNSDocumentScannerImpl.java:613)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:3079)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:836)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:542)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:889)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:825)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1224)
> at 
> java.xml/com.sun.org.apache.xerces.inter

[jira] [Commented] (XALANJ-2649) Xalan 2.7.3 is missing dependencies (Regression from 2.7.2)

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/XALANJ-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722355#comment-17722355
 ] 

Elliotte Rusty Harold commented on XALANJ-2649:
---

Bleah. I don't know what changed to omit the dependencies in **2.7.3**. 2.7.2 
looks right. 

> Xalan 2.7.3 is missing dependencies (Regression from 2.7.2)
> ---
>
> Key: XALANJ-2649
> URL: https://issues.apache.org/jira/browse/XALANJ-2649
> Project: XalanJ2
>  Issue Type: Bug
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: Build, Xalan
>Affects Versions: 2.7.3
>Reporter: mt
>Assignee: Gary D. Gregory
>Priority: Major
> Attachments: serializer-2.7.3.pom, xalan-2.7.3.pom
>
>
> After upgrading from 2.7.2 to 2.7.3 via maven central, we get the following 
> runtime error.
> It seems like 2.7.3 is missing the dependencies to serializer and xercesImpl 
> . After manually adding a dependency to serializer:2.7.3 , the issue is fixed.
> This can also be seen in Maven Central:
> [Maven Central: xalan:xalan:2.7.2 
> (sonatype.com)|https://central.sonatype.com/artifact/xalan/xalan/2.7.2/dependencies]
>  -> has dependencies on serializer and xercesImpl
> [Maven Central: xalan:xalan:2.7.3 
> (sonatype.com)|https://central.sonatype.com/artifact/xalan/xalan/2.7.3/dependencies]
>  -> no dependencies
>  
> {code:java}
> java.lang.NoClassDefFoundError: org/apache/xml/serializer/SerializerTrace
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1012)
> at 
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
> at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
> at 
> org.apache.xalan.processor.ProcessorStylesheetElement.getStylesheetRoot(ProcessorStylesheetElement.java:123)
> at 
> org.apache.xalan.processor.ProcessorStylesheetElement.startElement(ProcessorStylesheetElement.java:74)
> at 
> org.apache.xalan.processor.StylesheetHandler.startElement(StylesheetHandler.java:623)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:518)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:374)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook(XMLNSDocumentScannerImpl.java:613)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:3079)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:836)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:542)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:889)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:825)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1224)
> at 
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:637)
> at 
> org.apache.xalan.processor.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:917)
> at 
> org.apache.xalan.processor.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:771)
> {code}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (XALANJ-2649) Xalan 2.7.3 is missing dependencies (Regression from 2.7.2)

[Elliotte Rusty Harold (Jira)]

[ 
https://issues.apache.org/jira/browse/XALANJ-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722354#comment-17722354
 ] 

Elliotte Rusty Harold commented on XALANJ-2649:
---

"As far as I can tell it has significance only for Maven builds (which Xalan is 
currently not):"

This **NOT** true. The parent reference can contribute to the dependency tree 
of all projects that consume this pom.xml. It is not only relevant to the 
building of Xalan itself. 

I don't know what changed to omit the dependencies in 2.7.2, but if they are 
required at runtime then they should be in the pom.xml that is published to 
Maven Central. Tentatively, I'd rate this bug critical and worth an emergency 
fix in advance of all other current work. 

> Xalan 2.7.3 is missing dependencies (Regression from 2.7.2)
> ---
>
> Key: XALANJ-2649
> URL: https://issues.apache.org/jira/browse/XALANJ-2649
> Project: XalanJ2
>  Issue Type: Bug
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: Build, Xalan
>Affects Versions: 2.7.3
>Reporter: mt
>Assignee: Gary D. Gregory
>Priority: Major
> Attachments: serializer-2.7.3.pom, xalan-2.7.3.pom
>
>
> After upgrading from 2.7.2 to 2.7.3 via maven central, we get the following 
> runtime error.
> It seems like 2.7.3 is missing the dependencies to serializer and xercesImpl 
> . After manually adding a dependency to serializer:2.7.3 , the issue is fixed.
> This can also be seen in Maven Central:
> [Maven Central: xalan:xalan:2.7.2 
> (sonatype.com)|https://central.sonatype.com/artifact/xalan/xalan/2.7.2/dependencies]
>  -> has dependencies on serializer and xercesImpl
> [Maven Central: xalan:xalan:2.7.3 
> (sonatype.com)|https://central.sonatype.com/artifact/xalan/xalan/2.7.3/dependencies]
>  -> no dependencies
>  
> {code:java}
> java.lang.NoClassDefFoundError: org/apache/xml/serializer/SerializerTrace
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1012)
> at 
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
> at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
> at 
> org.apache.xalan.processor.ProcessorStylesheetElement.getStylesheetRoot(ProcessorStylesheetElement.java:123)
> at 
> org.apache.xalan.processor.ProcessorStylesheetElement.startElement(ProcessorStylesheetElement.java:74)
> at 
> org.apache.xalan.processor.StylesheetHandler.startElement(StylesheetHandler.java:623)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:518)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:374)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook(XMLNSDocumentScannerImpl.java:613)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:3079)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:836)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:542)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:889)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:825)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse

[jira] [Updated] (XALANJ-2647) xslt 3.0 variable evaluations to node sets instead of RTF, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2647:
-
Description: To implement the concept of XSLT 3.0 variables evaluating to 
node sets instead of XML result tree fragments (RTFs). Attached is a zip 
archive having, few working test cases for this jira issue.  (was: To implement 
the concept of XSLT 3.0 variables evaluating to node sets instead of XML result 
tree fragments (RTFs).)

> xslt 3.0 variable evaluations to node sets instead of RTF, for xalanj 
> interpretive processor
> 
>
> Key: XALANJ-2647
> URL: https://issues.apache.org/jira/browse/XALANJ-2647
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: xsl3_variable_evaluations_to_nodesets_test_files.zip
>
>
> To implement the concept of XSLT 3.0 variables evaluating to node sets 
> instead of XML result tree fragments (RTFs). Attached is a zip archive 
> having, few working test cases for this jira issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2647) xslt 3.0 variable evaluations to node sets instead of RTF, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2647:
-
Attachment: xsl3_variable_evaluations_to_nodesets_test_files.zip

> xslt 3.0 variable evaluations to node sets instead of RTF, for xalanj 
> interpretive processor
> 
>
> Key: XALANJ-2647
> URL: https://issues.apache.org/jira/browse/XALANJ-2647
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: xsl3_variable_evaluations_to_nodesets_test_files.zip
>
>
> To implement the concept of XSLT 3.0 variables evaluating to node sets 
> instead of XML result tree fragments (RTFs).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2647) xslt 3.0 variable evaluations to node sets instead of RTF, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2647:
-
Attachment: (was: test3.xsl)

> xslt 3.0 variable evaluations to node sets instead of RTF, for xalanj 
> interpretive processor
> 
>
> Key: XALANJ-2647
> URL: https://issues.apache.org/jira/browse/XALANJ-2647
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
>
> To implement the concept of XSLT 3.0 variables evaluating to node sets 
> instead of XML result tree fragments (RTFs).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2647) xslt 3.0 variable evaluations to node sets instead of RTF, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2647:
-
Attachment: (was: test1.xsl)

> xslt 3.0 variable evaluations to node sets instead of RTF, for xalanj 
> interpretive processor
> 
>
> Key: XALANJ-2647
> URL: https://issues.apache.org/jira/browse/XALANJ-2647
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
>
> To implement the concept of XSLT 3.0 variables evaluating to node sets 
> instead of XML result tree fragments (RTFs).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2647) xslt 3.0 variable evaluations to node sets instead of RTF, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2647:
-
Attachment: (was: test4.xsl)

> xslt 3.0 variable evaluations to node sets instead of RTF, for xalanj 
> interpretive processor
> 
>
> Key: XALANJ-2647
> URL: https://issues.apache.org/jira/browse/XALANJ-2647
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
>
> To implement the concept of XSLT 3.0 variables evaluating to node sets 
> instead of XML result tree fragments (RTFs).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2647) xslt 3.0 variable evaluations to node sets instead of RTF, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2647:
-
Attachment: (was: test2.xsl)

> xslt 3.0 variable evaluations to node sets instead of RTF, for xalanj 
> interpretive processor
> 
>
> Key: XALANJ-2647
> URL: https://issues.apache.org/jira/browse/XALANJ-2647
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
>
> To implement the concept of XSLT 3.0 variables evaluating to node sets 
> instead of XML result tree fragments (RTFs).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2647) xslt 3.0 variable evaluations to node sets instead of RTF, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2647:
-
Attachment: (was: test1_b.xml)

> xslt 3.0 variable evaluations to node sets instead of RTF, for xalanj 
> interpretive processor
> 
>
> Key: XALANJ-2647
> URL: https://issues.apache.org/jira/browse/XALANJ-2647
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: test1.xsl, test2.xsl, test3.xsl, test4.xsl
>
>
> To implement the concept of XSLT 3.0 variables evaluating to node sets 
> instead of XML result tree fragments (RTFs).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2647) xslt 3.0 variable evaluations to node sets instead of RTF, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2647:
-
Attachment: (was: test1_a.xml)

> xslt 3.0 variable evaluations to node sets instead of RTF, for xalanj 
> interpretive processor
> 
>
> Key: XALANJ-2647
> URL: https://issues.apache.org/jira/browse/XALANJ-2647
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: test1.xsl, test2.xsl, test3.xsl, test4.xsl
>
>
> To implement the concept of XSLT 3.0 variables evaluating to node sets 
> instead of XML result tree fragments (RTFs).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2647) xslt 3.0 variable evaluations to node sets instead of RTF, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2647:
-
Description: To implement the concept of XSLT 3.0 variables evaluating to 
node sets instead of XML result tree fragments (RTFs).  (was: To implement the 
concept of XSLT 3.0 variables, evaluating to node sets instead of XML result 
tree fragments (RTFs).)
Summary: xslt 3.0 variable evaluations to node sets instead of RTF, for 
xalanj interpretive processor  (was: xslt 3.0 variable evaluations to node sets 
instead of RTF)

> xslt 3.0 variable evaluations to node sets instead of RTF, for xalanj 
> interpretive processor
> 
>
> Key: XALANJ-2647
> URL: https://issues.apache.org/jira/browse/XALANJ-2647
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: test1.xsl, test1_a.xml, test1_b.xml, test2.xsl, 
> test3.xsl, test4.xsl
>
>
> To implement the concept of XSLT 3.0 variables evaluating to node sets 
> instead of XML result tree fragments (RTFs).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2648) xslt 3.0, to implement nodesets instead of RTF for xsl:with-param element, for xalanj interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2648:
-
Summary: xslt 3.0, to implement nodesets instead of RTF for xsl:with-param 
element, for xalanj interpretive processor  (was: xslt 3.0, to implement 
nodesets instead of RTF for xsl:with-param element)

> xslt 3.0, to implement nodesets instead of RTF for xsl:with-param element, 
> for xalanj interpretive processor
> 
>
> Key: XALANJ-2648
> URL: https://issues.apache.org/jira/browse/XALANJ-2648
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: test1.xsl, test1_a.xml
>
>
> As per XSLT 3.0 spec, to implement nodesets instead of RTF (XML result tree 
> fragments) for xsl:with-param element.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2648) xslt 3.0, to implement nodesets instead of RTF for xsl:with-param element

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2648:
-
Attachment: test1.xsl

> xslt 3.0, to implement nodesets instead of RTF for xsl:with-param element
> -
>
> Key: XALANJ-2648
> URL: https://issues.apache.org/jira/browse/XALANJ-2648
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: test1.xsl, test1_a.xml
>
>
> As per XSLT 3.0 spec, to implement nodesets instead of RTF (XML result tree 
> fragments) for xsl:with-param element.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2648) xslt 3.0, to implement nodesets instead of RTF for xsl:with-param element

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2648:
-
Attachment: (was: test1.xsl)

> xslt 3.0, to implement nodesets instead of RTF for xsl:with-param element
> -
>
> Key: XALANJ-2648
> URL: https://issues.apache.org/jira/browse/XALANJ-2648
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: test1_a.xml
>
>
> As per XSLT 3.0 spec, to implement nodesets instead of RTF (XML result tree 
> fragments) for xsl:with-param element.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2646) Implementation of xslt 3.0's xsl:for-each-group instruction, for XalanJ's interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2646:
-
Attachment: xsl3_for_each_group_test_files.zip

> Implementation of xslt 3.0's xsl:for-each-group instruction, for XalanJ's 
> interpretive processor
> 
>
> Key: XALANJ-2646
> URL: https://issues.apache.org/jira/browse/XALANJ-2646
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: Xalan-interpretive
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: xsl3_for_each_group_test_files.zip
>
>
> I'm creating this jira issue, to track implementation of XSLT 3.0's 
> xsl:for-each-group instruction, for XalanJ's interpretive processor.
> I've done little bit of implementation for this, that seems to work fine for 
> various primary XSLT 3.0 xsl:for-each-group use cases.
> The XSLT 3.0 structural implementation for xsl:for-each-group, implementing 
> the XSLT element xsl:for-each-group, and functions fn:current-group(), 
> fn:current-grouping-key() have been completed. All the xsl:for-each-group's 
> grouping attributes, i.e 'group-by', 'group-adjacent', 'group-starting-with', 
> 'group-ending-with' have been implemented.
> Implementation of using xsl:sort element(s) with xsl:for-each-group element 
> has been fairly completed. The XSLT 3.0 spec, specifies following grammar for 
> xsl:sort element,
> select? = expression
>lang? = { language }
>order? = { "ascending" | "descending" }
>collation? = { uri }
>stable? = { boolean }
>case-order? = { "upper-first" | "lower-first" }
>data-type? = { "text" | "number" | eqname } >
> 
> 
> Except the xsl:sort element's attributes 'collation' and 'stable', all other 
> attributes of xsl:sort element have been implemented to work with 
> xsl:for-each-group element.
> Currently, xsl:for-each-group's grouping keys (i.e, value of xslt 3.0 
> function fn:current-grouping-key() for a group) can have values typed as 
> string, number or boolean (any other XPath typed value for xslt 3.0's 
> grouping keys is converted to a string value).
> The relevant working test cases, for this jira issue have been attached as 
> zip archive to this jira issue.  
> The codebase changes for these mentioned XSLT 3.0 implementation aspects, 
> have been committed to xalan-java repo's branch xalan-j_xslt3.0.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2646) Implementation of xslt 3.0's xsl:for-each-group instruction, for XalanJ's interpretive processor

[Mukul Gandhi (Jira)]

 [ 
https://issues.apache.org/jira/browse/XALANJ-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mukul Gandhi updated XALANJ-2646:
-
Attachment: (was: xsl3_for_each_group_test_files.zip)

> Implementation of xslt 3.0's xsl:for-each-group instruction, for XalanJ's 
> interpretive processor
> 
>
> Key: XALANJ-2646
> URL: https://issues.apache.org/jira/browse/XALANJ-2646
> Project: XalanJ2
>  Issue Type: New Feature
>  Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>  Components: Xalan-interpretive
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
>
> I'm creating this jira issue, to track implementation of XSLT 3.0's 
> xsl:for-each-group instruction, for XalanJ's interpretive processor.
> I've done little bit of implementation for this, that seems to work fine for 
> various primary XSLT 3.0 xsl:for-each-group use cases.
> The XSLT 3.0 structural implementation for xsl:for-each-group, implementing 
> the XSLT element xsl:for-each-group, and functions fn:current-group(), 
> fn:current-grouping-key() have been completed. All the xsl:for-each-group's 
> grouping attributes, i.e 'group-by', 'group-adjacent', 'group-starting-with', 
> 'group-ending-with' have been implemented.
> Implementation of using xsl:sort element(s) with xsl:for-each-group element 
> has been fairly completed. The XSLT 3.0 spec, specifies following grammar for 
> xsl:sort element,
> select? = expression
>lang? = { language }
>order? = { "ascending" | "descending" }
>collation? = { uri }
>stable? = { boolean }
>case-order? = { "upper-first" | "lower-first" }
>data-type? = { "text" | "number" | eqname } >
> 
> 
> Except the xsl:sort element's attributes 'collation' and 'stable', all other 
> attributes of xsl:sort element have been implemented to work with 
> xsl:for-each-group element.
> Currently, xsl:for-each-group's grouping keys (i.e, value of xslt 3.0 
> function fn:current-grouping-key() for a group) can have values typed as 
> string, number or boolean (any other XPath typed value for xslt 3.0's 
> grouping keys is converted to a string value).
> The relevant working test cases, for this jira issue have been attached as 
> zip archive to this jira issue.  
> The codebase changes for these mentioned XSLT 3.0 implementation aspects, 
> have been committed to xalan-java repo's branch xalan-j_xslt3.0.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org