Hi Joe,

here is the change, rebased for JDK10:
http://cr.openjdk.java.net/~clanger/webrevs/8168664-10.0/

This version would never generate prefixes for xsl:element and hence I removed 
the check for the property. Also Aleksej's test 
test/javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java needs to go 
then as it would be obsolete and would fail. Other than that, I ran the jtreg 
tests and found no other issues.

Thanks
Christoph


From: huizhe wang [mailto:huizhe.w...@oracle.com]
Sent: Donnerstag, 9. Februar 2017 17:25
To: Langer, Christoph <christoph.lan...@sap.com>
Cc: core-libs-dev@openjdk.java.net; Aleksej Efimov <aleksej.efi...@oracle.com>
Subject: Re: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates 
namespace prefixes if namespace is given as URI only


On 2/7/2017 11:28 PM, Langer, Christoph wrote:
Hi Joe,

welcome back.

Thanks!


This sounds reasonable. I'll prepare a change for JDK10.

Hopefully it'd open soon so that you don't have to keep it for too long.

Best,
Joe



Thanks
Christoph

From: Joe Wang [mailto:huizhe.w...@oracle.com]
Sent: Mittwoch, 8. Februar 2017 01:39
To: Langer, Christoph 
<christoph.lan...@sap.com><mailto:christoph.lan...@sap.com>
Cc: core-libs-dev@openjdk.java.net<mailto:core-libs-dev@openjdk.java.net>; 
Aleksej Efimov <aleksej.efi...@oracle.com><mailto:aleksej.efi...@oracle.com>
Subject: Re: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates 
namespace prefixes if namespace is given as URI only

Hi Christoph,

As we discussed, let's target this for JDK 10 as a spec change at this stage 
for JDK 9 is too late. Removing the namespace generation would be another 
reason to do this in JDK 10 since then, we wouldn't need the additional 
property.

Thanks,
Joe

On 1/31/17, 11:02 AM, Langer, Christoph wrote:
Hi Joe,

evenutally I have updated my webrev for this issue: 
http://cr.openjdk.java.net/~clanger/webrevs/8168664.1/<http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664.1/>

I've implemented your suggestion to add a property "jdk.xml.generatePrefix" 
which is true by default. I also added a testcase which tests the correct 
behavior with "-Djdk.xml.generatePrefix=false".

Generally, I think namespace prefix generation at this place is not needed. Or 
would you know of or be able to construct a case where it is really required? 
If not, I rather think namespace generation at this place should be thrown out 
unconditionally. Maybe for JDK10? In case it is removed, it would render the 
test javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java which was 
implemented recently by Alex for bug 
https://bugs.openjdk.java.net/browse/JDK-8167179 obsolete in its current form. 
However, the namespace generation function is still used some place for 
attribute namespaces.

For JDK9 I can imagine the change of this webrev going in - however, as we 
already discussed, you would have to do a ccc for me.

Thanks & Best regards
Christoph

From: Langer, Christoph
Sent: Dienstag, 25. Oktober 2016 15:39
To: core-libs-dev@openjdk.java.net<mailto:core-libs-dev@openjdk.java.net>
Subject: RFR (JAXP): 8168664 [JAXP] XALAN: xsl:element generates namespace 
prefixes if namespace is given as URI only

Hi JAXP experts,

please review a fix for a new issue regarding namespace handling in Xalan with 
xsl:element.

Bug: https://bugs.openjdk.java.net/browse/JDK-8168664
Webrev: 
http://cr.openjdk.java.net/~clanger/webrevs/8168664.0/<http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664.0/>

I'm not 100% sure if this is the right way to go or if it would break some 
correct behavior elsewhere. But I think the current behavior is either not 
correct or at least it is not required to generate new xsl namespace prefixes 
if the namespace comes in as URI only to an xsl:element node. The 
interpretative transformer from the Apache Xalan project will also produce the 
expected output, different to the compiled XSLTC here.

In the webrev, my changes to XslElement.java are only cosmetical/comments, the 
behavior does not change. In BasisLibrary.java I also took the opportunity to 
remove the $Id tag and the unused method "nodeList2IteratorUsingHandleFromNode".

If you think my change is good, I'll also add a test that runs the 
transformation which can be found in the bug...

Thanks & best regards
Christoph


Reply via email to