Bug #4338: Prefixes for default attribute coming from associated XML Schema are no longer output in the output root element - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #4338

closed

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

Added by Radu Coravu about 5 years ago. Updated about 5 years ago.

Status:

Closed

Priority:

Low

Assignee:

Michael Kay

Category:

Sprint/Milestone:

Start date:

2019-10-11

Due date:

% Done:

Estimated time:

Legacy ID:

Applies to branch:

Fix Committed on Branch:

Fixed in Maintenance Release:

Platforms:

Description

Attaching a set of XML + XSD. At some point in "https://saxonica.plan.io/issues/3068" 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.getConfiguration().setConfigurationProperty(
        FeatureKeys.SCHEMA_VALIDATION_MODE,
        Validation.toString(Validation.STRICT));
  
    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("http://apache.org/xml/features/validation/schema", true);
    saxParser.setFeature(Constants.SAX_FEATURE_PREFIX + Constants.VALIDATION_FEATURE, true);
    
    xmlSource.setXMLReader(saxParser);
  
    // Output stream result
    File outFile = new File("test/EXM-35876/out.xml");
    if (outFile.exists()) {
      outFile.delete();
    }
    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="http://www.w3.org/2001/XMLSchema-instance"
    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.

Files

EXM-35876.zip (2.28 KB) EXM-35876.zip

Radu Coravu, 2019-10-11 07:09

Related issues

Actions

Copy link

Updated by Michael Kay about 5 years 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.

Actions

Copy link

Updated by Michael Kay about 5 years ago

Status changed from New to AwaitingInfo

Actions

Copy link

Updated by Radu Coravu about 5 years 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' -- http://dita-ot.sourceforge.net/ns/201007/dita-ot
>    [filter] *** net.sf.saxon.event.ComplexContentOutputter.namespace(NamespaceBinding, int)
>    [filter] Declare namespace '' -- http://dita.oasis-open.org/architecture/2005/
>    [filter] pendingStartTag is class net.sf.saxon.om.NoNamespaceName
>    [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(ComplexContentOutputter.java:372)
>    [filter] 	at net.sf.saxon.event.ComplexContentOutputter.checkProposedPrefix(ComplexContentOutputter.java:521)
>    [filter] 	at net.sf.saxon.event.ComplexContentOutputter.startContent(ComplexContentOutputter.java:677)
>    [filter] 	at net.sf.saxon.event.ProxyReceiver.startContent(ProxyReceiver.java:177)
>    [filter] 	at net.sf.saxon.event.ReceivingContentHandler.startElement(ReceivingContentHandler.java:370)
>    [filter] 	at org.dita.dost.writer.DitaWriterFilter.startElement(DitaWriterFilter.java:180)
>    [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.

Actions

Copy link