Saxon add a random xmlns attribute

Question

I generate svg with batik.

Then I do some post processing on the svg by loading it, modify it, then save it back to file.

    public void doStuff(File sourceF, File destination) {
        DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

        DocumentBuilder db;
        try {
            dbf.setValidating(false);
            dbf.setNamespaceAware(true);
            dbf.setFeature("http://xml.org/sax/features/namespaces", false);
            dbf.setFeature("http://xml.org/sax/features/validation", false);
            dbf.setFeature("http://apache.org/xml/features/nonvalidating/load-dtd-grammar", false);
            dbf.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);

            
            
            db = dbf.newDocumentBuilder();
            Document doc = db.parse(sourceF);
            
            //here I do some dom manipulation moving child around

            //then save :

            DOMSource source = new DOMSource(doc);
            FileOutputStream fos = new FileOutputStream(destination);
            Writer out = new OutputStreamWriter(fos, "UTF-8");
            StreamResult result = new StreamResult(out);

            TransformerFactory transformerFactory = TransformerFactory.newInstance();
            Transformer transformer = transformerFactory.newTransformer();
            transformer.setOutputProperty(OutputKeys.ENCODING, "UTF-8");
            transformer.transform(source, result);

With the default internal jdk xerces factory is used the svg it correct.

When I have Saxon in the classpath, it uses the TransformerFactory from Saxon. The output is almost the same but it add a xmlns="" on the first "g" and "defs" making it displaying white in browser.

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" contentScriptType="text/ecmascript" contentStyleType="text/css" height="847" preserveAspectRatio="xMidYMid meet" style="stroke-dasharray:none; shape-rendering:auto; font-family:'Dialog'; text-rendering:auto; fill-opacity:1; color-interpolation:auto; color-rendering:auto; font-size:12px; fill:black; stroke:black; image-rendering:auto; stroke-miterlimit:10; stroke-linecap:square; stroke-linejoin:miter; font-style:normal; stroke-width:1; stroke-dashoffset:0; font-weight:normal; stroke-opacity:1;" version="1.0" width="651" zoomAndPan="magnify">
    <!--Generated by the Batik Graphics2D SVG Generator-->
    <defs xmlns="" id="genericDefs">
        <style type="text/css" xml:space="preserve">svg { fill-rule: evenodd;pointer-events: none;}.hotspot { cursor: pointer;pointer-events: all;}@keyframes blink {100%,0% {fill: transparent;}60% {fill: #f00;}}.hotspotBlink {animation: blink 0.25s 3;}</style>
    </defs>
    <g xmlns="">

I can force a newInstance() to get a xerces implementation, but if I realy would like to use Saxon, how could I avoid this xmlns to be added ?

Answer 1

It's hard to answer this without knowing exactly what is in the DOM that you have constructed. Saxon clearly thinks that the defs and g elements are in no namespace, and has generated the xmlns="" attributes to reflect this. Exactly why it has come to this conclusion isn't clear, because you haven't shown the code that constructed the DOM.

Note that you're using the JAXP Transformer here to do an identity transformation from the DOM to the serializer. But the serialization specs are defined in terms of the XDM data model, not in terms of DOM, and there is essentially no definitive specification for how an arbitrary DOM should be translated to the XDM data model. This is often a problem in edge cases, which can easily arise in a programmatically-constructed DOM, because DOM imposes very few consistency constraints; for example you can create an element in a particular namespace without creating a namespace declaration for that namespace, or even with an inconsistent declaration of that namespace; it's not entirely surprising that different implementations of JAXP should handle such cases in different ways.

It's also unsurprising, given the absence of any specs or agreed reference tests, that bugs should be found and fixed from time to time in this area. It would therefore be useful to know which Saxon version you are using. An example of a bug fixed in the last year is https://saxonica.plan.io/issues/5859 and you will find others if you search on the keywords "DOM" and "namespace".