Bug #4338

Prefixes for default attribute coming from associated XML Schema are no longer output in the output root element

Added by Radu Coravu 12 months ago. Updated 11 months ago.

Start date:
Due date:
% Done:


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


Attaching a set of XML + XSD. At some point in "" the issue was fixed but a related problem seems to have appeared again in Saxon 9.9.

The core to reproduce this is something like:

 public static void main(String[] args) throws SAXNotRecognizedException, SAXNotSupportedException, TransformerException {
    File xslFile = new File("test/EXM-35876/copy_stylesheet.xsl");
    InputSource inputSource = new InputSource(xslFile.toURI().toString());
    Source source = new SAXSource(inputSource);
    TransformerFactoryImpl transformerFactory = new EnterpriseTransformerFactory();
    transformerFactory.setAttribute(net.sf.saxon.lib.FeatureKeys.XSLT_SCHEMA_AWARE, true);
    Transformer transformer = transformerFactory.newTransformer(source);
    // Create XML SAX source
    InputSource inputSource2 = new InputSource(new File("test/EXM-35876/defAttr.xml").toURI().toString());
    SAXSource xmlSource = new SAXSource(inputSource2);
    SAXParser saxParser = new SAXParser();
    //EXM-11081 Set this feature so that the default attributes from the schema are reported...
    saxParser.setFeature("", true);
    saxParser.setFeature(Constants.SAX_FEATURE_PREFIX + Constants.VALIDATION_FEATURE, true);
    // Output stream result
    File outFile = new File("test/EXM-35876/out.xml");
    if (outFile.exists()) {
    Result outputTarget = new StreamResult(outFile);
    // Run transformation
    transformer.transform(xmlSource, outputTarget);

and the output file:

<?xml version="1.0" encoding="UTF-8"?>
<root xmlns:gns2="testNS" xmlns:xsi=""
    xsi:noNamespaceSchemaLocation="main.xsd" attr1="defVal" DITAArchVersion="defVal"/>

so you can see that in the output both default attributes (attr1 and DITAArchVersion)appear to be in no namespace although both attribute names should be prefixed and in the correct namespace. (2.28 KB) Radu Coravu, 2019-10-11 07:09


#1 Updated by Michael Kay 12 months ago

As far as I can see Xerces is reporting the expanded default attribute via the SAX interface in such a way that Attributes.getQName(i) returns a simple local name, so Saxon cannot tell that the attribute is in a namespace.

This example seems to be rather confusing since schema validation is being performed first by Xerces and then again by Saxon. If we cut out the Xerces validation and do Saxon validation alone, then the defaulted attributes end up being correctly namespace-qualified.

#2 Updated by Michael Kay 12 months ago

  • Status changed from New to AwaitingInfo

#3 Updated by Radu Coravu 12 months ago

The initial problem was when running DITA OT transformations (which set that VALIDATION feature on the SAX parser in order to expand default @class attribute values from XML Schemas). At that moment in time Oxygen used its Saxon EE to run the DITA OT transformation and that produced the following error in the console:

>    [filter] Declare namespace 'dita-ot' --
>    [filter] *** net.sf.saxon.event.ComplexContentOutputter.namespace(NamespaceBinding, int)
>    [filter] Declare namespace '' --
>    [filter] pendingStartTag is class
>    [filter] elementIsInNullNamespace: 'true'
>    [filter] !!!Cannot output a namespace node for the default namespace when the element is in no namespace
>    [filter] java.lang.Exception
>    [filter] 	at net.sf.saxon.event.ComplexContentOutputter.namespace(
>    [filter] 	at net.sf.saxon.event.ComplexContentOutputter.checkProposedPrefix(
>    [filter] 	at net.sf.saxon.event.ComplexContentOutputter.startContent(
>    [filter] 	at net.sf.saxon.event.ProxyReceiver.startContent(
>    [filter] 	at net.sf.saxon.event.ReceivingContentHandler.startElement(
>    [filter] 	at org.dita.dost.writer.DitaWriterFilter.startElement(
>    [filter] 	at org.xml.sax.helpers.XMLFilterImpl.startElement(Unknown Source)

My colleague who investigated the problem managed to reproduce the problem with that small test case I pasted above. For some time now we have been using the DITA Open Toolkit's bundled Saxon library to run the publishing process so this problem no longer is relevant. I even tried to run the DITA OT transformation with a licensed Saxon 9.9 but it no longer seems to show the original problem. So I'll probably comment out this automatic test on my side and we'll leave it at that as I no longer have a way in which an end user could reproduce the problem from inside Oxygen.

#4 Updated by Michael Kay 11 months ago

  • Status changed from AwaitingInfo to Closed
  • Assignee set to Michael Kay

Closing this, as there doesn't seem to be anything further we can do about this problem.

Please register to edit this issue

Also available in: Atom PDF