kibook

44ffdf5 should fix the use of XPath prefixes, as long as they have been properly declared in the BREX XML. I mentioned declaring them on the `` element before, but...

Since S1000D (Issue 4.0+) does recommend XPath 2.0 in the specification, I'm looking in to extending libxml2's XPath support. I'm not sure it can be made fully compliant to XPath...

Do you know if you use XPath 2.0-specific features besides functions, such as the `if` or `for` keywords? I'm not sure if those can be implemented as easily as adding...

Thanks for the list! However, after looking more into XPath 2.0, I don't think just adding XPath 2.0-like functions will be enough. For example, the way the `tokenize` function is...

I have added an experimental option to use Saxon to evaluate the objectPath instead of libxml2. In my tests, it worked successfully on all the example XPath 2.0-based rules you...

Did you build with: ``` $ make BREXCHECK_XPATH_ENGINE=saxon ``` From your errors, it is still using libxml2's XPath engine. You can check which engine it uses with: ``` $ s1kd-brexcheck...

Thanks for the info! I got the same error too when I gave it a quick try. The basic issue seems to be that Cygwin/MinGW are counted as Windows in...

I updated the Makefile in a236fa1 to treat Cygwin and MinGW as Linux when compiling the Saxon/C API, *except* for SaxonCGlue.c, which contains the hardcoded path to the shared library....

In the Makefile output, do you see `-D__linux__` in the `gcc` and `g++` commands (except for the one compiling `SaxonCGlue.c`)? That is what should cause it to use the "linux"...

Try exporting the OSTYPE environment variable to make sure it is visible to `make`: ``` $ export OSTYPE $ make BREXCHECK_XPATH_ENGINE=saxon ``` If that works, you can add `export OSTYPE`...