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
*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
