XPath expression error in Schematron file for 5.2b10a5?

[tomschr]

Problem

As version 5.2b10a5 is out, I've play a bit around with oXygen. For the sake of simplicity, I've configured my oXygen editor to use version 5.2b10a5 when I request "5.2". Whenever I write "5.2", I mean the latest version.

First, I've started with this structure for version 5.1:

<?xml-model href="http://docbook.org/xml/5.1/rng/docbook.rng"
            schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="http://docbook.org/xml/5.1/sch/docbook.sch"
            schematypens="http://purl.oclc.org/dsdl/schematron"
            type="application/xml" ?>
<article xmlns="http://docbook.org/ns/docbook" version="5.1">
    <title/>
    <para/>
</article>

This is a perfectly valid DocBook 5.1 structure. My oXygen editor reports a green light.

However, if I change the <?xml-model?> PI from 5.1 to 5.2, the latest version is loaded into oXygen but I get the following message (linebreaks by me to improve readability):

Error in expression every $id in tokenize(current()/@arearefs) satisfies
 (every $ar in //*[@xml:id = $id] satisfies 
 (local-name($ar) = ('areaset', 'area', 'co') and
 namespace-uri($ar) = 'http://docbook.org/ns/docbook')):
Unexpected token $ beyond end of expression

It points to the file sch/5.2/docbook.sch and the following location (line 11):

   <s:pattern>
      <s:title>Callout cross reference constraint</s:title>
      <s:rule context="db:callout[@arearefs]">
         <s:assert test="every $id in tokenize(current()/@arearefs) satisfies (every $ar in //*[@xml:id = $id] satisfies (local-name($ar) = ('areaset', 'area', 'co') and namespace-uri($ar) = 'http://docbook.org/ns/docbook'))">@arearefs on callout must point to a areaset, area, or co.</s:assert>
      </s:rule>
   </s:pattern>

Possible solution

If I compare it with the previous version, there is no db:callout[@arearefs] pattern. This must be introduced in version 5.2.

Unfortunately, I'm not familiar with XPath 2.0 so I cannot make any educated suggestion. Maybe review the above expression again?

[ndw]

How odd. It certainly passes in the DocBook unit tests and I've just cut-and-pasted the expression into a stylesheet and it works fine. I'll investigate a bit further, but I wonder if this is an Oxygen bug.

[tomschr]

Thanks for investigating. For the record, I've used version 23.1, build 2021040908. I'll install a newer maintenance version and see how it goes. Maybe this "bug" will dissapear.

[ndw]

I suppose it's possible that the every ... satisfies ... expression actually requires XPath 3.0, but it doesn't appear to at a casual glance. If that's the case, I'll propose removing it.

[tomschr]

Same with oXygen 23.1 build 2021061407.

I suppose it's possible that the every ... satisfies ... expression actually requires XPath 3.0, but it doesn't appear to at a casual glance. If that's the case, I'll propose removing it.

I suspected that too, but had no proof. Could the expression be rewritten as XPath 2.0? Maybe the underlying validator only recognize 2.0 and not 3.0.

I can try to report it to the oXygen crew, if you think this could be helpful.

[tomschr]

If I'm not mistaken, wasn't there an attribute for the Schematron schema to indicate which XPath version to use? Unfortunately, I hardly remember the name.

There is a schemaVersion attribute for the s:schema root element. However, I think, this reflects the Schematron version and not the used XPath version.

[tomschr]

Found it: it's queryBinding; oXygen gives this popup menu as an explanaition:

"The optional queryBinding attribute provides the short name of the query language binding in use. If this attribute is specified, it is an error if it has a value that the current implementation does not support."

You can choose from different languages, xpath2, xslt3, and more. That line helped me to avoid the previous error:

<s:schema xmlns:db="http://docbook.org/ns/docbook" queryBinding="xslt3"

@ndw Would that be a useful addition?

(For some unknown reason, xpath3 does not work.)

[ndw]

Yes, that's probably the thing to do. Should test that what it means is that a processor incapable of providing an xslt3 binding simply ignores it and doesn't always report an error.

[ndw]

Turns out queryBinding applies to the whole schema, not individual patterns. That's kind of a drag. On the other hand, setting queryBinding to xslt2 is sufficient to fix the problem. I guess the default implementation in the absence of a binding is still XSLT 1.0.

On the one hand, I think all the significant Schematron implementations today support XSLT 2.0. On the other, this is going to disable all the Schematron assertions in environments where the older implementations are in use.

Options:

1. Set the queryBinding to xslt2, "full speed ahead, damn the torpedos!"
2. Remove Schematron constraint on callout/@arearefs
3. Produce two versions of the Schematron rules

I suspect the least worst answer is 2. I'm not sure the complexity of producing and explaining two different Schematron schemas is worth the effort.

[kosek]

It's 2021 so might be we can try option 1 and see if there will be complaints...

[ndw]

It's very tempting. If, as I expect, the overwhelming majority of users who are using the Schematron rules at all are doing so in Oxygen which will work just fine with an xslt2 queryBinding, then it'd be just fine.