Bug #2795
closedError message "Value of {cdata-section-elements} must be a list of QNames in '{uri}local' notation"
100%
Description
When executing the below code I obtain this exception:
Exception in thread "main" java.lang.IllegalArgumentException: Value of {cdata-section-elements} must be a list of QNames in '{uri}local' notation
at net.sf.saxon.s9api.Serializer.setOutputProperty(Serializer.java:490)
at net.sf.saxon.jaxp.TransformerImpl.transform(TransformerImpl.java:142)
at com.oxygenxml.transformer.XSLOutputException.main(XSLOutputException.java:44)
Source xslSource = new StreamSource(new StringReader("<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n" +
"<xsl:stylesheet xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\"\n" +
" version=\"1.0\">\n" +
" \n" +
" <xsl:output cdata-section-elements=\"MASTER_COMMENTS\"/>\n" +
" \n" +
" <xsl:template match=\"@* | node()\">\n" +
" <xsl:copy>\n" +
" <xsl:apply-templates select=\"@* | node()\"/>\n" +
" </xsl:copy>\n" +
" </xsl:template>\n" +
"</xsl:stylesheet>"));
Transformer newTransformer = TransformerFactoryImpl.newInstance().newTransformer(xslSource);
String outputProperty = newTransformer.getOutputProperty("cdata-section-elements");
System.out.println("cdata-section-elements " + outputProperty);
Source xmlSource = new StreamSource(new StringReader("<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n" +
"<MASTER_COMMENTS>\n" +
"</MASTER_COMMENTS>"));
StringWriter writer = new StringWriter();
Result outputTarget = new StreamResult(writer);
newTransformer.transform(xmlSource, outputTarget);
System.out.println(writer.toString());
The strange part is that the exception is triggered by the presence of this line of code:
String outputProperty = newTransformer.getOutputProperty("cdata-section-elements");
As far as I can tell, net.sf.saxon.lib.SaxonOutputKeys.parseListOfNodeNames(String, NamespaceResolver, boolean, boolean, String) builds clark notations like {}MASTER_COMMENTS
and a bit later SaxonOutputKeys.checkListOfClarkNames considers them invalid.
Updated by Michael Kay almost 8 years ago
- Category set to JAXP Java API
- Status changed from New to In Progress
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Found in version deleted (
9.6.09) - Applies to branch 9.6, 9.7, 9.8 added
- Fixed in Maintenance Release 9.7.0.4 added
- Fixed in Maintenance Release deleted (
9.7.0.5, 9.6.0.9)
Bug confirmed on the 9.6 and 9.7 branches; unit test jaxptest/SerializerTests/testCdataSectionProperty added.
Updated by Michael Kay almost 8 years ago
Yes, rather remarkable!
Saxon internally replaces QName-valued serialization properties with the Clark format "{uri}local" so that there is no context-dependency on namespace declarations. But it seems that one particular path is generating the form "{}local" for a no-namespace name, while the code that validates serialization properties doesn't recognize this form and expects plain "local".
I haven't quite worked out why the call on getOutputProperty() should trigger this, except that it seems it triggers extraction of the properties into JAXP format, and subsequently if they exist in this form then this is the form that is used.
Updated by Michael Kay almost 8 years ago
- Status changed from In Progress to Resolved
- Fix Committed on Branch 9.6, 9.7, 9.8 added
Patched on the 9.6, 9.7, and 9.8 branches: SaxonOutputKeys.isValidClarkName() now accepts {}LOCAL
for names in no namespace.
Updated by O'Neil Delpratt almost 8 years ago
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.7.0.6 added
- Fixed in Maintenance Release deleted (
9.7.0.4)
Bug fix applied in the Saxon 9.7.0.6 maintenance release. Leave open until bug fix applied in the Saxon 9.6 maintenance release.
Updated by Guillermo Fernandes over 7 years ago
Hi,
Would it be possible to get this fixed in 9.6.x?
Thanks
Updated by Guillermo Fernandes over 7 years ago
Hi,
I would need this fixed in 9.6.x too. Is there any plan to get it patched in 9.6?
Thanks
Updated by Michael Kay over 7 years ago
Is there a good reason that you can't move forward to 9.7? We can't keep maintaining old releases for ever.
(Do you have a support contract? In this kind of situation, we're more inclined to help paying customers.)
Updated by Guillermo Fernandes over 7 years ago
Ok, no problem, the reason was that when we tried 9.7.x we found that the performance for different transformations was impacted.
We could try again with latest 9.7.x version and see how it perform.
Thanks
Updated by O'Neil Delpratt over 7 years ago
- Status changed from Resolved to Closed
- Fixed in Maintenance Release 9.6.0.10 added
Bug fix applied in the Saxon 9.6.0.10 maintenance release.
Updated by O'Neil Delpratt almost 7 years ago
- Applies to branch trunk added
- Applies to branch deleted (
9.8)
Updated by O'Neil Delpratt almost 7 years ago
- Fix Committed on Branch trunk added
- Fix Committed on Branch deleted (
9.8)
Please register to edit this issue