Altova MapForce 2023 Basic Edition

This section:

•Engine conformance

•Schema awareness

•Encoding

•Namespaces

•XML source and validation

•Static and dynamic type checking

•Library modules

•External functions

•Collations

•Precision of numeric data

•XQuery instructions support

•Implementation-specific behavior

Conformance

The XQuery 1.0 Engine of MapForce conforms to the World Wide Web Consortium's (W3C's) XQuery 1.0 Recommendation of 14 December 2010. The XQuery standard gives implementations discretion about how to implement many features. Given below is a list explaining how the XQuery 1.0 Engine implements these features.

Schema awareness

The XQuery 1.0 Engine is schema-aware.

Encoding

The UTF-8 and UTF-16 character encodings are supported.

Namespaces

The following namespace URIs and their associated bindings are pre-defined.

The following points should be noted:

•The XQuery 1.0 Engine recognizes the prefixes listed above as being bound to the corresponding namespaces.

•Since the built-in functions namespace listed above (see fn:) is the default functions namespace in XQuery, the fn: prefix does not need to be used when built-in functions are invoked (for example, string("Hello") will call the fn:string function). However, the prefix fn: can be used to call a built-in function without having to declare the namespace in the query prolog (for example: fn:string("Hello")).

•You can change the default functions namespace by declaring the default function namespace expression in the query prolog.

•When using types from the XML Schema namespace, the prefix xs: may be used without having to explicitly declare the namespaces and bind these prefixes to them in the query prolog. (Example: xs:date and xs:yearMonthDuration.) If you wish to use some other prefix for the XML Schema namespace, this must be explicitly declared in the query prolog. (Example: declare namespace alt = "http://www.w3.org/2001/XMLSchema"; alt:date("2004-10-04").)

•Note that the untypedAtomic, dayTimeDuration, and yearMonthDuration datatypes have been moved, with the CRs of 23 January 2007, from the XPath Datatypes namespace to the XML Schema namespace, so: xs:yearMonthDuration.

If namespaces for functions, type constructors, node tests, etc are wrongly assigned, an error is reported. Note, however, that some functions have the same name as schema datatypes, e.g. fn:string and fn:boolean. (Both xs:string and xs:boolean are defined.) The namespace prefix determines whether the function or type constructor is used.

XML source document and validation

XML documents used in executing an XQuery document with the XQuery 1.0 Engine must be well-formed. However, they do not need to be valid according to an XML Schema. If the file is not valid, the invalid file is loaded without schema information. If the XML file is associated with an external schema and is valid according to it, then post-schema validation information is generated for the XML data and will be used for query evaluation.

Static and dynamic type checking

The static analysis phase checks aspects of the query such as syntax, whether external references (e.g. for modules) exist, whether invoked functions and variables are defined, and so on. If an error is detected in the static analysis phase, it is reported and the execution is stopped.

Dynamic type checking is carried out at run-time, when the query is actually executed. If a type is incompatible with the requirement of an operation, an error is reported. For example, the expression xs:string("1") + 1 returns an error because the addition operation cannot be carried out on an operand of type xs:string.

Library Modules

Library modules store functions and variables so they can be reused. The XQuery 1.0 Engine supports modules that are stored in a single external XQuery file. Such a module file must contain a module declaration in its prolog, which associates a target namespace. Here is an example module:

module namespace libns="urn:module-library";

declare variable \$libns:company := "Altova";

declare function libns:webaddress() { "https://www.altova.com" };

All functions and variables declared in the module belong to the namespace associated with the module. The module is used by importing it into an XQuery file with the import module statement in the query prolog. The import module statement only imports functions and variables declared directly in the library module file. As follows:

import module namespace modlib = "urn:module-library" at "modulefilename.xq";  

External functions

External functions are not supported, i.e. in those expressions using the external keyword, as in:

declare function hoo(\$param as xs:integer) as xs:string external;  

Collations

The default collation is the Unicode-codepoint collation, which compares strings on the basis of their Unicode codepoint. Other supported collations are the ICU collations listed here. To use a specific collation, supply its URI as given in the list of supported collations. Any string comparisons, including for the fn:max and fn:min functions, will be made according to the specified collation. If the collation option is not specified, the default Unicode-codepoint collation is used.

Precision of numeric types

•The xs:integer datatype is arbitrary-precision, i.e. it can represent any number of digits.

•The xs:decimal datatype has a limit of 20 digits after the decimal point.

•The xs:float and xs:double datatypes have limited-precision of 15 digits.

XQuery Instructions Support

The Pragma instruction is not supported. If encountered, it is ignored and the fallback expression is evaluated.

Implementation-specific behavior

Given below is a description of how the XQuery and XQuery Update 1.0 engines handle implementation-specific aspects of certain functions.

unparsed-text

The href argument accepts (i) relative paths for files in the base-uri folder, and (ii) absolute paths with or without the file:// protocol. Additionally supported encodings are (the Altova-specific): x-binarytobase16 and x-binarytobase64. Example: xs:base64Binary(unparsed-text('chart.png', 'x-binarytobase64')).

unparsed-text-available

The href argument accepts (i) relative paths for files in the base-uri folder, and (ii) absolute paths with or without the file:// protocol. Additionally supported encodings are (the Altova-specific): x-binarytobase16 and x-binarytobase64.