Advanced Topics - eXist: A NoSQL Database and Application Development Platform - page 477

The classes of each have mostly the same names but are maintained in different pack‐
ages. The Java classes for the in-memory implementation of XDM node types are in
the package org.exist.memtree , while the persistent DOM implementations are in
the package org.exist.dom . See Table 16-7 .

Table 16-7. XDM node type mappings

XDM node type eXist's Java class
node NodeImpl
attribute AttrImpl (DOM) / AttributeImpl (memtree)
comment CommentImpl
document DocumentImpl
element ElementImpl
processing-instruction ProcessingInstructionImpl
text TextImpl

While all function parameters in eXist are sequences , the cardinality of these parame‐
ters is constrained in the definition of the function signature. eXist provides cardinal‐
ity constants that model the occurrence indicators used for function parameters in
the XQuery specification. These cardinality constants are defined in the class
org.exist.xquery.Cardinality (see Table 16-8 ).

Table 16-8. XQuery occurrence mappings

XQuery occurrence
indicator

eXist's cardinality constant

Cardinality.EXACTLY_ONE (when explicitly typed)/ Cardinality.ZERO_OR_MORE
(when not explicitly typed)

?

Cardinality.ZERO_OR_ONE

*

Cardinality.ZERO_OR_MORE

+

Cardinality.ONE_OR_MORE

Function Parameters and Return Types
Now that we have an understanding of how XDM types are implemented by eXist in
Java, we can consider how we might use these to accept parameters to our functions
or return certain result types. When you're implementing a function for an internal
module, it helps to think of the function as a transformation from an array of sequen‐
ces to a sequence . For example, the eval function of your BasicFunction will be
passed a Java array of org.exist.xquery.value.Sequence objects and must either
throw an org.exist.xquery.XPathException or return a Sequence . Sequences are
also described in the XDM specification, and can basically be thought of as collec‐