Loading TOC...
XQuery and XSLT Reference Guide (PDF)

XQuery and XSLT Reference Guide — Chapter 2

XQuery Dialects in MarkLogic Server

The XQuery specification is a formal recommendation from the W3C XQuery Working Group. MarkLogic 8 implements the W3C XQuery 1.0 Recommendation (). To maximize compatibility with MarkLogic Server 3.2 and to offer strict XQuery compliance to those who desire it, as well as to include extensions to the language to make it easier to build applications, MarkLogic Server supports three dialects of XQuery. This chapter describes these dialects, and includes the following sections:

Overview of the XQuery Dialects

MarkLogic Server supports three dialects separate dialects of XQuery:

You can use library modules from different dialects together, as described in Rules For Combining the Dialects. Each dialect has a different set of pre-defined namespaces, as described in Predefined Namespace Prefixes for Each Dialect.

MarkLogic Server Enhanced (XQuery 1.0-ml)

For a module to use the MarkLogic Server enhanced dialect, use the following for the XQuery version declaration on the first line of the XQuery module:

xquery version "1.0-ml";

Note the semi-colon at the end of the declaration, which is required in 1.0-ml. The enhanced dialect has the XQuery 1.0 syntax and also includes various extensions to the language such as try/catch. This dialect is the default for new App Servers, and should be considered the preferred dialect for new applications. For more details on the enhanced 1.0-ml dialect, see MarkLogic Server Enhanced XQuery Language.

MarkLogic Server 3.2 Compatibility (XQuery 0.9-ml)

For a module to use the MarkLogic Server 3.2 compatibility dialect, use the following for the XQuery version declaration on the first line of the XQuery module:

xquery version "0.9-ml"

Note there is no semi-colon at the end of the declaration for 0.9-ml. The 3.2 compatibility dialect allows you to write code that you can use with both 3.2 and 4.0. Any code you have from 3.2 releases is equivalent to 0.9-ml. To use that code in 4.0, the best practice is to add the 0.9-ml XQuery declaration (shown above) as the first line of each XQuery module.

Strict (XQuery 1.0)

For a module to use the MarkLogic Server strict dialect, use the following for the XQuery version declaration on the first line of the XQuery module:

xquery version "1.0";

Note the semi-colon at the end of the declaration, which is required in 1.0. The strict mode is for compatibility with other XQuery 1.0 processors; if you write a library in 1.0, you can use it with MarkLogic Server and you can also use it with other conforming processors. Similarly, you can use modules that are written in standard XQuery with MarkLogic Server.

To use the MarkLogic Server built-in functions in 1.0, you must bind a prefix (for example, xdmp) to the namespace for the MarkLogic Server functions; there is no need to import a library for these built-in functions, but you do need to bind the namespace to a prefix. To use the xdmp functions in 1.0, add prolog entries for the namespace bindings you are using in your query, as in the following example:

xquery version "1.0";
declare namespace xdmp = "http://marklogic.com/xdmp";


Rules For Combining the Dialects

MarkLogic Server has a very flexible way of combining the three XQuery dialects. You can import a library module written in any of the three dialects into any main or library module. For example, you might find an open source standards-compliant module that you found on the internet which is written in the strict XQuery 1.0 dialect. You can then import this module into any MarkLogic Server XQuery program, regardless of dialect, and then use those functions in your code.

When writing modules of different dialects, the best practice is to always use the XQuery version declaration as the first line, indicating which dialect the module is written in. That way, if the module is written in a different dialect than the default dialect for the App Server or the program, it will still work correctly (for details, see Inheriting the Default XQuery Version From the App Server).

Using a Non-Default Dialect in XSLT (xdmp:dialect)

You can use the xdmp:dialect attribute to specify which dialect expressions are evaluated in an XSLT stylesheet. For details, see xdmp:dialect Attribute.

Strategies For Migrating Code to Enhanced Dialect

If you are writing new XQuery code, the best practice is to use the 1.0-ml dialect. If you are updating code that was written in previous versions of MarkLogic Server, you can consider if you want to migrate that code to 1.0-ml. This section describes things to think about when migrating your application code and includes the following parts:

When To Migrate XQuery Code

Because of the flexibility of how you can interoperably use the various XQuery dialects, it is really up to you when and how you migrate your XQuery code. The differences between the dialects are mostly syntax changes in the prolog, but there are also some other differences that might cause subtle changes in behavior. For details on the differences between the XQuery dialects in 3.2 (0.9-ml) and 4.0 (1.0-ml), see XQuery Changes From Previous MarkLogic Server Releases. When you decide to migrate XQuery code to 1.0-ml (or to 1.0), there are several ways you can go about it:

  • Migrate an entire application all at once. This method gets everything over with at once, and therefore focuses the effort. If you have a relatively small amount of code to migrate, it might make sense to just go ahead and migrate it all at once.
  • Migrate one module at a time. This method allows you to spread the migration work over a number of small tasks instead of one large task, and further allows you to test each module independently after migration. This technique is very flexible, as you can do a little bit at a time. A good first step for this one-by-one approach is to start by adding an XQuery 0.9-ml declaration to the first line of each XQuery file. Then, as you migrate a module, you can change the declaration to 1.0-ml and make any needed syntax changes to that module.

XQuery Changes From Previous MarkLogic Server Releases

While MarkLogic Server 4.0 includes a compatibility dialect to run your 3.2 code without changes (0.9-ml), the new enhanced mode offers several important improvements, so it is a good idea to migrate your code to the enhanced dialect (1.0-ml). Because you can mix modules in the old dialect with modules in the new, you can perform your migration one module at a time. This section highlights the major syntax and semantic changes between the XQuery used in MarkLogic Server 3.2 (0.9-ml) and MarkLogic Server 4.0 enhanced XQuery dialect (1.0-ml). Additionally, see the 'Known Incompatibilities' section of the Release Notes. The changes include:

  • Semi-colons ( ; ) are now required at the end of each prolog declaration.
  • Prolog declarations that previously used define now use declare.
  • Variable declaration syntax is slightly different, and now uses the := syntax (for details and an example, see Declaring Variables).
  • Library module declarations now require the namespace keyword and a prefix for the namespace, for example:
    module namespace my = "my-namespace";
  • Function declarations that return the empty sequence now require the empty sequence to be specified as follows:

    In 0.9-ml, you specify empty() for the empty sequence.

  • Some of the effective boolean value rules have changed. Notably, the following returns true in 0.9-ml and returns false in 1.0-ml (and throws an exception in 1.0):
    (: returns true in 0.9-ml, false in 1.0-ml, and
       throws XDMP-EFFBOOLVALUE in 1.0 :)
    fn:boolean((fn:false(), fn:false()))

    This change might affect applications that have if/then/else statements where the if test returns a sequence of boolean values. In these cases, you might see the if statement evaluating to false in cases where it previously evaluated to true, causing the else statement to be evaluated intead of the then statement.

  • The namespace used for durations now uses the xs namespace prefix; previously it was the xdt prefix. Any code you have that uses the xdt namespace prefix will require a change to the xs prefix. For example, if you have code that uses xdt:dayTimeDuration, you should change that to xs:dayTimeDuration.
  • element() tests in 0.9-ml are equivalent to schema-element() test in 1.0 and 1.0-ml. Any code you have with element() tests might not match some elements that previously matched. For example, substitution elements previously would match the base element name, but will now only match with schema-element() test in 1.0 and 1.0-ml. For more information, see in the 4.0 Release Notes.
  • Some changes to the XQuery standard functions. For example, there are subtle changes to fn:avg and fn:sum, fn:error has a different signature, and fn:node-kind does not exist in 1.0 and 1.0-ml (it is replaced by xdmp:node-kind).

Inheriting the Default XQuery Version From the App Server

Each App Server has a setting for the default XQuery version. Any requests against that App Server that do not have explicitly specify an XQuery version declaration are treated as the default XQuery version value. Because of the way a request inherits it default XQuery version from the App Server environment, requests without an explicit declaration can be treated differently by different App Servers (if the App Servers have different default XQuery values). Therefore, it is best practice to specify the XQuery version in each module.

The task server does not allow you to specify a default XQuery version, and if there is no explicit version declaration in the XQuery code evaluated on the task server, the default XQuery version is determined as follows:

  • If you run an xdmp:spawn call, the default XQuery version is 1.0-ml.
  • If a trigger action module is executed on the task server (for example, as the result of an update on a document that has a post-commit update trigger), then the default XQuery version is the default XQuery version for the App Server that triggered the update (as specified in the configuration for the App Server).

This makes it especially important to use XQuery version declarations in modules used by CPF or modules called from triggers. For details on CPF, see the Content Processing Framework Guide.

To ensure your code is always evaluated in the dialect in which you have written it, regardless of the context in which it is run, the best practice is to begin each XQuery module with a XQuery version declaration. For the syntax of the version declaration, see XQuery Version Declaration.

Specifying the XQuery Dialect in the Prolog

You specify the dialect for an XQuery module with a version declaration. The version declaration is optional, and comes before the prolog in an XQuery module. It is best practice to put the XQuery version declaration in your code as the first line in the module, as having it there ensures it will work as expected in any environment. For example, to specify 1.0-ml as the XQuery version, begin your XQuery module with the following:

xquery version "1.0-ml";

Porting 3.2 (0.9-ml) XQuery Code to Enhanced (1.0-ml)

In most cases, porting any XQuery code used in 3.2 to the 1.0-ml dialect will be easy and straightforward. The bulk of the differences are syntax changes in the prolog. As stated earlier, you do not need to port all of your code at one time. A sensible approach is to migrate your code one XQuery module at a time. This section outlines the basic steps you should follow when migrating your XQuery code.

The following are some basic steps to take when migrating 3.2 XQuery code (0.9-ml) to 4.0 (1.0-ml):

  1. Add XQuery version declarations to all of your existing modules. For code written in 3.2, the declarations will be as follows:
    xquery version "0.9-ml"
  2. Review the Release Notes for any incompatibilities.
  3. For each module you migrate, change the version number string in the XQuery version declaration to 1.0-ml and add a semi-colon to the line so it looks as follows
    xquery version "1.0-ml";
  4. Change all of the prolog declarations to the 1.0 syntax (change define to declare, add semi-colons, and so on, as described in XQuery Changes From Previous MarkLogic Server Releases). For the prolog syntax, see XQuery Prolog, the W3C specification (http://www.w3.org/TR/xquery/#id-grammar), or a third-party XQuery book.
  5. If you are modifying a main module and it has function declarations that are used in the same module, they must be declared in a namespace. The preferred way to put functions local to a main module is to prefix those functions definitions and function calls with the local: prefix, which is predefined.
  6. If you have any durations that use the xdt namespace prefix, change the prefix to xs (for example, change xdt:dayTimeDuration to xs:dayTimeDuration).
  7. If you are modifying a library module, all XQuery standard functions need to be prefixed with the fn namespace prefix. Alternately, you can declare the XQuery functions namespace as the default function namespace in the prolog as follows:
    declare default function namespace

    If you do declare the default function namespace, then you will also need to prefix your own function definitions with the prefix defined in your module definition. Note that you can no longer use the XPath functions namespace as the library module namespace.

  8. If you are modifying a library module that is defined with the fn namespace URI, you must change the namespace URI of that module; you cannot use the URI bound to the fn namespace prefix as the URI for a library module in 1.0 or 1.0-ml. If you do change the namespace URI of a library module, you must also change the URI in any import module statements in other modules that call the library.
  9. Test the module and correct any syntax errors that occur.
  10. After getting the module to run, test your code to make sure it behaves as it did before. Pay particular attention to parts of your code that might rely on boolean values that take boolean values of sequences, as those behave differently in 0.9-ml and 1.0-ml (see XQuery Changes From Previous MarkLogic Server Releases). Check for any changes due to function mapping, which is described in Function Mapping.
  11. Repeat this process for other modules you want to migrate.
« Previous chapter
Next chapter »
Powered by MarkLogic Server 7.0-4.1 and rundmc | Terms of Use | Privacy Policy