Thanks, Christian. Your answers are helpful.

It sounds like someone can test an XQuery 1.0 module using XSpec and BaseX 12.0 if the 1.0 code they're testing behaves the same way in XQuery 1.0 and 4.0.

Best regards, Amanda

On Monday, September 29th, 2025 at 12:03 PM, Christian Grün cg@basex.org wrote:

Hi Amanda,

I think the answer is simple: We interpret everything as XQuery 4.0, and the declared version declaration does not really matter (even though we check it for being valid… which may be misleading).

Early versions of BaseX parsed 1.0 and 3.0 code differently, but as the vast majority of users did not really care about the version declaration, we decided to drop all this extra work.

A side effect of this is that we ignore the implications of minor backward-compatibilities. This has not been a real issue in the last years (for the users that we were in contact with), but if it turns out that it will become an issue with 4.0, we will certainly react on this.

Feel free to dig deeper if you have open questions. Christian

---

Von: Amanda Galtman via BaseX-Talk basex-talk@mailman.uni-konstanz.de Gesendet: Montag, 29. September 2025 16:26 An: basex-talk@mailman.uni-konstanz.de basex-talk@mailman.uni-konstanz.de Betreff: [basex-talk] XQuery version declarations and combinations

Hi, BaseX creators and users.

I have several questions about XQuery versions:

1. The main documentation page [1] for BaseX 12.0 calls it an XQuery 4.0 processor. The XQuery 4.0 draft specification [2] says in section 5.1, "The XQuery 4.0 specification does not attempt to define the semantics of a query in which different modules use different version numbers. One approach is to process all modules as if they specified version "4.0". Another approach (which may be appropriate if modules are separately compiled) is to process each module using its own version number; but it is then implementation defined what happens if (say) a 3.1 module imports a 4.0 library module that declares a function with a signature that 3.1 does not recognize." The question is: What does BaseX do if a 3.0 main module imports a 1.0 library module?

2. That same section 5.1 says, "An XQuery 4.0 processor must accept a module in which the version number is given as "1.0", "3.0", or "3.1". It is then implementation defined whether the module is processed using the syntax and semantics of the XQuery 4.0 specification, or the rules of the relevant earlier version." What does BaseX do for pre-4.0 queries?

3. For the BaseX versions in the not-too-distant past that called themselves XQuery 3.1 processors, is the answer to question 2 analogous? (I don't see the same "processor must accept..." verbiage in the XQuery 3.1 specification [3], though.)

4. (Not BaseX-specific) If a main module declares version "1.0" and uses a post-1.0 feature like URI-qualified names, that's a bug in the module, right? Even if the main module imports a 1.0 module, and even if the processor doesn't complain about the post-1.0 feature usage?

5. (Not BaseX-specific) The 3.1 and 4.0 (draft) specifications explain the version declaration in terms of intent ("intent that the module be processed by an XQuery [...] processor"), which is a different criterion compared to stating the *minimum* XQuery version that would work for that module. If anyone on this list uses the "minimum" interpretation in practice, do you have any tips for efficiently determining the minimum required XQuery version for each module in a set of modules?

The background behind my questions involves an XSpec test for an XQuery module, where the test gets compiled to a main module that imports the module you are testing. The main module uses features from 3.0, so I'm trying to determine the extent to which someone can test a 1.0 module using XSpec.

Thanks, Amanda

References:

[1] https://docs.basex.org/main/Main_Page [2] https://qt4cg.org/specifications/xquery-40/xquery-40.html#id-version-declara... [3] https://www.w3.org/TR/xquery-31/#id-version-declaration