Project

Profile

Help

Bug #2364

closed

Cannot transform an XSLT stylesheet when the xsl:output contains unknown attributes

Added by Radu Pisoi almost 9 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
JAXP Java API
Sprint/Milestone:
Start date:
2015-04-28
Due date:
% Done:

100%

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

Description

I get the next exception when I'm running an XSLT transformation using a JAXP transformer:

java.lang.IllegalArgumentException: Unknown serialization property {http://www.w3.org/XML/1998/namespace}space
	at net.sf.saxon.s9api.Serializer.getProperty(Serializer.java:735)
	at net.sf.saxon.jaxp.TransformerImpl.transform(TransformerImpl.java:138)
	at ro.sync.exml.editor.xmleditor.TransformationAssistant.applyTransformation(TransformationAssistant.java:2368)
	at ro.sync.exml.editor.xmleditor.TransformationAssistant.applyTransformationOrFop(TransformationAssistant.java:1589)
	at ro.sync.exml.editor.xmleditor.TransformationAssistant$4.appRun(TransformationAssistant.java:1175)
	at ro.sync.ui.application.ApplicationThread.run(ApplicationThread.java:135)

Stylesheet:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    exclude-result-prefixes="xs"
    version="2.0">
    
    <xsl:output xml:space="preserve"></xsl:output>
    
    <xsl:template match="node() | @*">
        <xsl:copy>
            <xsl:apply-templates select="node() | @*"/>
        </xsl:copy>
    </xsl:template>        
</xsl:stylesheet>
Actions #1

Updated by Michael Kay almost 9 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

Although I can see from the stack trace where it's breaking, I haven't actually managed to construct an example that reproduces the problem, so it's not obvious where to fix it. The method that breaks (Serializer.getProperty()) is behaving as specified by rejecting an unknown property, so I think it's better to fix the caller; but I can't reproduce the sequence of events that causes the caller to make this request.

Actions #2

Updated by Radu Pisoi almost 9 years ago

I can reproduce the problem if I request one of the output properties or all properties before running the transformation:

String encoding = transformer.getOutputProperty("encoding");
System.out.println("Encoding " + encoding);

// The problem can also be reproduced if I request all the output properties
// transformer.getOutputProperties();		

transformer.transform(xmlSource, outputTarget);
Actions #3

Updated by Radu Pisoi almost 9 years ago

I get the same exception if I run a transformation that uses the saxon:next-in-chain attribute on the xsl:output instruction.

So, basically, the saxon:next-in-chain extension cannot be used with oXygen 17 that comes bundled with Saxon 9.6.0.5.

Actions #4

Updated by Michael Kay almost 9 years ago

The situation arises essentially because the set of serialization properties supported in xsl:output and in the JAXP API is extensible, while the set of properties supported in the s9api Serializer is fixed (it's defined by a Java enum). This causes a conflict now that JAXP is implemented on top of the s9api interface.

We can solve the problem fairly easily by dropping the unrecognized attributes somewhere along the line before they cause a failure. However, this isn't a 100% satisfactory solution, because the SerializerFactory mechanism in principle allows users to define their own customized serialization methods that have the ability to make use of additional serialization properties. So a better solution would be to make the s9api Serializer property set extensible. However, it's not easy to do this while retaining 100% compatibility. So I'm thinking in terms of a 9.6 fix that drops the extension attribute, and a 9.7 fix that makes the s9api Serializer extensible.

Actions #5

Updated by Michael Kay almost 9 years ago

  • Status changed from In Progress to Resolved
  • Found in version changed from 9.6.0.5 to 9.6

I decided to fix this (on both the 9.6 and 9.7 branches) by adding methods getOutputProperty(QName) and setOutputProperty(QName, String) to the s9api serializer, allowing non-standard serialization attributes to be passed to this class.

(It's a little odd that the extension attributes are passed through this interface as a side-effect of getting one output property. But the way JAXP defines the semantics of getOutputProperties() is such that there's not much choice: as soon as the used asks for a property, we make a local copy of all the properties, and at transform() time, we pass the modified set of properties back to the s9api Serializer).

Actions #6

Updated by O'Neil Delpratt almost 9 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in version set to 9.6.0.6

Bug fix applied in the Saxon 9.6.0.6 maintenance release.

Actions #7

Updated by Radu Pisoi over 8 years ago

I have encountered a similar problem when running an XSLT transformation through JAXP API wih Saxon 9.6.0.6. In this case I have used xsl:output/@cdata-section-elements attribute instead of saxon:next-in-chain.

Exception stack trace:

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:471)
	at net.sf.saxon.jaxp.TransformerImpl.transform(TransformerImpl.java:136)
	at ro.sync.exml.editor.xmleditor.TransformationAssistant.applyTransformation(TransformationAssistant.java:2370)
	at ro.sync.exml.editor.xmleditor.TransformationAssistant.applyTransformationOrFop(TransformationAssistant.java:1591)
	at ro.sync.exml.editor.xmleditor.TransformationAssistant$4.appRun(TransformationAssistant.java:1177)
	at ro.sync.ui.application.ApplicationThread.run(ApplicationThread.java:135)

Could you also analyse this case?

Actions #8

Updated by O'Neil Delpratt over 8 years ago

  • Sprint/Milestone set to 9.6.0.6
  • Applies to branch 9.6 added
  • Fix Committed on Branch 9.6 added
  • Fixed in Maintenance Release 9.6.0.6 added

Please register to edit this issue

Also available in: Atom PDF