Hi Christoph,
I totally understand the desire to get it out of your backlog. However,
we do need a compatibility review for this change. The details for JDK
10 Compatibility & Specification Review are still in the works. It's
unfortunate that we do have to wait a bit. Please refer to
http://mail.openjdk.java.net/pipermail/announce/2017-February/000219.html.
For the change, the property jdk.xml.generatePrefix needs to be
supported by the API as well as a System property since it's more
specifically a XML Transform feature. Take a look at
jdk.xml.internal.JdkXmlFeatures, you may add a feature for
jdk.xml.generatePrefix similar to USE_CATALOG, set the default value
(the 3rd parameter) to false, e.g.:
GENERATE_PREFIX(PROPERTY_GENERATE_PREFIX, SP_GENERATE_PREFIX,
false, false, true, false);
JdkXmlFeatures can then be used to manage the new feature. Test then
needs to be added to verify the support of the feature by the Transform
API (e.g. factory.setFeature).
Thanks,
Joe
On 2/21/2017 10:19 AM, Langer, Christoph wrote:
Hi Joe,
please finally review this fix for JDK10:
http://cr.openjdk.java.net/~clanger/webrevs/8168664-10.1/
<http://cr.openjdk.java.net/%7Eclanger/webrevs/8168664-10.1/>
This version contains the Java property “jdk.xml.generatePrefix” which
we should have no matter on which default we decide. In my customer
base I have customers that need it either way – depending from where
their legacy apps or custom developments come, XALAN XSLTC or other
XML frameworks.
This proposal sets the prefix generation default for xsl:element to
false – maybe we should try it for 10? Also, do we need a ccc for 10?
I would appreciate if I could get this item completed soon as I want
to get it out of my backlog.
Thanks and best regards
Christoph
*From:*Langer, Christoph
*Sent:* Montag, 13. Februar 2017 16:15
*To:* 'huizhe wang' <huizhe.w...@oracle.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
Hi Joe,
here is the change, rebased for JDK10:
http://cr.openjdk.java.net/~clanger/webrevs/8168664-10.0/
<http://cr.openjdk.java.net/%7Eclanger/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
<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
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
<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