New pull event API XSLT problems

Added by Michal Kotelba over 7 years ago

I'm using v.9.7.0.7 and attempting to switch from using PullSource -> StaxBridge to PullEventSource -> StaxToEventBridge, specifically as the Source for several different situations. Either API stack works perfectly fine for DocumentBuilder, Serializer, etc, but attempting to compile a XSLT (v.2.0) stylesheet makes the inner guts of XsltCompiler choke:


Mode name {dsdl:go} is not a valid QName
Caused by: net.sf.saxon.trans.XPathException: Mode name {dsdl:go} is not a valid QName
        at net.sf.saxon.style.StyleElement.compileError(StyleElement.java:2408)
        at net.sf.saxon.style.XSLApplyTemplates.prepareAttributes(XSLApplyTemplates.java:84)
        at net.sf.saxon.style.StyleElement.processAttributes(StyleElement.java:604)
        at net.sf.saxon.style.StyleElement.processAllAttributes(StyleElement.java:550)
        at net.sf.saxon.style.StyleElement.processAllAttributes(StyleElement.java:555)
        at net.sf.saxon.style.PrincipalStylesheetModule.processAllAttributes(PrincipalStylesheetModule.java:547)
        at net.sf.saxon.style.PrincipalStylesheetModule.preprocess(PrincipalStylesheetModule.java:371)
        at net.sf.saxon.style.Compilation.compilePackage(Compilation.java:221)
        at net.sf.saxon.style.StylesheetModule.loadStylesheet(StylesheetModule.java:260)
        at net.sf.saxon.style.Compilation.compileSingletonPackage(Compilation.java:101)
...

My EventListener is also catching similar errors for XPath expressions used in various XSL attributes (i.e. value-of's select) that contain/use previously defined namespaces.

From what I can tell, the StaxToEventBridge is failing to keep track of the tree's namespaces ("dsdl" is properly set via an xmlns attribute on the document element).

Should I be wrapping the StaxToEventBridge in some sort of EventIterator wrapper before I put it in a PullEventSource? I tried NamespaceMaintainer, but it didn't help.

Replies (3)

Please register to reply

RE: New pull event API XSLT problems - Added by Michael Kay over 7 years ago

It does look as if namespace events aren't coming through correctly: this will tend to show up with XSLT as it makes heavy use of "QNames in content".

I've written a unit test which confirms the problem.

RE: New pull event API XSLT problems - Added by Michal Kotelba over 7 years ago

Just a thought, but EventToStaxBridge does automatically create a NamespaceMaintainer in it's constructor, whereas StaxToEventBridge seemingly never cares about namespaces not declared on the current element (and only if the current event type == START_ELEMENT?) ...

Is there a read-side equivalent of NamespaceReducer somewhere in Saxon's API?

RE: New pull event API XSLT problems - Added by Michael Kay over 7 years ago

Logged here:

https://saxonica.plan.io/issues/2901

The fix is while processing the StartElement event, to do:

            int nscount = reader.getNamespaceCount();
            for (int i = 0; i < nscount; i++) {
                String prefix = reader.getNamespacePrefix(i);
                if (prefix == null) {
                    prefix = "";
                }
                String uri = reader.getNamespaceURI(i);
                if (uri == null) {
                    uri = "";
                }
                see.addNamespace(new NamespaceBinding(prefix, uri));
            }

(1-3/3)

Please register to reply

Project

Profile

Help

Saxon