Project

Profile

Help

Bug #2795

closed

Error message "Value of {cdata-section-elements} must be a list of QNames in '{uri}local' notation"

Added by Alex Jitianu almost 8 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
JAXP Java API
Sprint/Milestone:
-
Start date:
2016-06-14
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.6, 9.7, trunk
Fix Committed on Branch:
9.6, 9.7, trunk
Fixed in Maintenance Release:
Platforms:

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.

Actions #1

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.

Actions #2

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.

Actions #3

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.

Actions #4

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.

Actions #5

Updated by Guillermo Fernandes over 7 years ago

Hi,

Would it be possible to get this fixed in 9.6.x?

Thanks

Actions #6

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

Actions #7

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.)

Actions #8

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

Actions #9

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.

Actions #10

Updated by O'Neil Delpratt almost 7 years ago

  • Applies to branch trunk added
  • Applies to branch deleted (9.8)
Actions #11

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

Also available in: Atom PDF