RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only
huizhe wang
huizhe.wang at oracle.com
Thu Feb 9 16:25:15 UTC 2017
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.wang at oracle.com]
> *Sent:* Mittwoch, 8. Februar 2017 01:39
> *To:* Langer, Christoph <christoph.langer at sap.com>
> *Cc:* core-libs-dev at openjdk.java.net; Aleksej Efimov
> <aleksej.efimov at 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 at openjdk.java.net
> <mailto:core-libs-dev at 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
>
More information about the core-libs-dev
mailing list