$msgs
. Similarly, the expressiondoc()
function
call applied to the context item:file:list
function, an extension function defined by the EXPath community group ([true
, the file search is extended to all sub
directories of the specified directory. A slight modification of the code
suffices to feed the catalog with the contents of docs.xml
), an
expression likedoc(.)
, make the extended path the
right-hand operand of a simple map expression (E1 ! E2) and add a left-hand
operand (some expression E) producing a stream of URIs:return
clause of a FLWOR expression and adding to the path an
initial step referencing a FLWOR variable, e.g.:doc(.)
step resolving the URIs and trailing steps which move into the resulting
documents: $since
)$since
dategroup by
clause of FLWOR expressions is well suited for such purposes. To give an
example, the following code extracts from a set of documents all
flight
elements, groups them by the departure airport and
reports for each departure airport the respective arrival airports:booking
elements found in a set of documents. The elements are copied into the result
document, including attributes and all descendant nodes. The next example does
not copy the elements, but represents them by short summary elements:kind='…'
) are in turn
embedded expressions navigating into the elements selected by the preceding path
step. Bringing into play the XQuery support for bulk navigation and adding to
the constructed elements information about their provenance, we achieve an
interesting result with very little code:booking
elements to a normalized format and the other
processing a normalized booking
element. The code navigates to
booking
elements and feeds a normalized version of each one to
a processing function. This example demonstrates the remarkable flexibility of
path expressions which can combine navigation with any operation mapping nodes
to other nodes - in this case navigation with transformation. typeswitch
expression which
enables transformation by recursive processing, copying some items unchanged and
modifying or deleting others. For example, the following query creates a
modified copy of the initial context document, deleting @foo
attributes, changing the value of @bar
attributes and adding to
<zoo>
elements a <timeStamp>
child
element:typeswitch
expression” enables convenient implementation of many transformation tasks. It
cannot, however, compare with the possibilities offered by XSLT and its template
model ([fn:transform
function which invokes an
XSLT stylesheet and returns the transformation result. As the result of an XSLT
transformation thus becomes the value of an XQuery expression, XSLT-powered
transformation is seamlessly integrated into the XQuery processing, as this
example demonstrates:transform
and copyModify
) which apply update
expression to xquery:eval
) supported by the BaseX processor:validate
expression,
which returns a copy of the validated document with type annotations added, or
raises an error in case of validation errors. Two points should be noted. First,
the goal to gather information about validity is different from the goal to
construct a type-annotated document, and it is the former goal which is common,
not so much the latter. Second, implementation of the validate
expression is not common among popular XQuery processors, especially among open
source products. We think that an XQuery function offering XSD validation is
desirable in general, and highly desirable in the context of data integration.
For the time being, several XQuery processors offer vendor-specific extension
functions for XSD-validation of XML documents. validate:xsd-info
. The query validates all XML documents found
in a directory tree and matching a file name pattern, against a schema which is
for each document automatically selected from all schemas found in a different
directory tree:@fooRef
attribute and
no child elements, or have child elements but no such attribute. Similarly,
there is no way to assert that an element must have an @approvedBy
attribute if the <amount> child element contains a value larger 1000. xquery:eval
, provided by the BaseX processor) for the dynamic
evaluation of XQuery expressions. Similar functions are offered by various
XQuery processors (e.g. Recource type | Input | Function | Source | XDM representation |
---|---|---|---|---|
XML document | URI | fn:doc | * | document-node() |
URI | fn:collection | * | node()* | |
text | fn:parse-xml | * | document-node() | |
text | fn:parse-xml-fragment | * | document-node() | |
HTML document | text | BaseX | document-node() | |
text | eXist-db | document-node() | ||
text | MarkLogic | document-node() | ||
JSON document | URI | fn:json-doc | * | map|array |
text | fn:parse-json | * | map|array | |
text | fn:json-to-xml | * | document-node() | |
text | BaseX | document-node() | ||
text | eXist-db | document-node() | ||
text | MarkLogic | element() | ||
CSV | text | BaseX | document-node() | |
text | URI | fn:unparsed-text | * | xs:string |
URI | fn:unparsed-text-lines | * | xs:string* | |
binary | URI | (*) | xs:base64Binary | |
URI | eXist-db | xs:base64Binary | ||
URI | BaseX | xs:base64Binary | ||
URI | MarkLogic | binary() (custom node) | ||
archive-entry | URI | (*) | xs:string | |
URI | (*) | xs:base64Binary | ||
URI | MarkLogic | document-node() | text() | xs:base64Binary | ||
SQL result set | query | BaseX | element()* | |
query | MarkLogic | array()*|map()* | ||
MongoDB result set | query | (*) | element()* | |
HTTP response | message | (*) | element()|xs:string |
file
module (archive
module (xs:base64Binary
representation, and binary data can also be
created by preparing an xs:base64Binary
representation and writing it
into a file or archive, which then receives the binary data corresponding to the
xs:base64Binary
representation.fn:doc
represents as a node tree. XQuery versions 3.0 and 3.1
broadened the scope of resource access significantly: any text-based resource can be
accessed as a string, and JSON documents can be accessed as structured information.
EXPath-defined as well as vendor-specific extension functions add further
possibilities (JSON parsing libraries have been observed to differ as to whether or not they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences.
true
:deep-equal (P(F1), P(S(P(F1))))
fn:json-doc
and
fn:json-to-xml
, one may observe these facts:fn:json-to-xml
) implies XDM-equal (by
fn:parse-json
), but not the other way around, as
differences in the order of object members preclude XDM-equality by
fn:json-to-xml
, but not by
fn:parse-json
.fn:json-to-xml
has a higher
format resolution than the binding fn:parse-json
.$m
) consists of nested maps and arrays.
Every JSON item – object, array, string, number, literal – is represented by a
distinct map entry or array member. It can be individually addressed by chaining map
and array lookups, which amounts to specifying a “path” of map entry names and/or
array index values. Every JSON item at an ?1
" or “?*
”). Therefore items cannot be addressed
without exact knowledge which object members along the path are single-valued and
which are array-valued. If, for example, the booking
member is a single
object, the following path might retrieve the bookingID
member of the
booking object:booking
member is an array of
objects - the path must be adapted:bookingID
member values of objects which are themselves
booking
member values. Dealing with a comparable XML document, the
retrieval would correspond to this path expression:$s
) as
produced by function fn:json-to-xml
, the booking IDs are retrieved by a
simple, though not very intuitive, expression:$b
), retrieval becomes even simpler:fn:json-to-xml
as well as
vendor-specific extension functions like BaseX-defined json:parse
and
csv:parse
demonstrate that various non-XML media types may be
represented as XML node trees, and the coexistence of the standard functions
fn:json-to-xml
and fn:json-doc
shows that for a given
media type different structured representations are possible. We acknowledge the
fact that a map/array representation has its own benefits compared with a node tree
representation – it is more light-weight, which means that it consumes less memory
and simple access operations are probably faster. But we also note that the question
whether a given media type can be represented by node trees or not decides whether
the media type in question is or is not fn:doc(REST-URI)//bookingID
)http:send-request
function can
be used for pulling SPARQL result sets into XQuery processing.group by
clause of a FLWOR expression iterating over the union of
all subject-backing nodes:group by
expression:$node
, the
grouping expression is then:group by
clause in
order to group subject-backing nodesgroup by
clause in order
to group object-backing nodesxs:schema
elements found in a set of XSDs. The triple set constructor makes each
xs:schema
element the subject of various triples providing target
namespace (predicate x:tns
), document URI (predicate
x:docURI
), imported schemas (predicate x:imports
) and
other properties.foo:search
is evaluated after
foo:openConnection
, not because its let
clause follows
the other let
clause – but because foo:search
cannot be
evaluated without the value of foo:openConnection
– provided the code
of foo:search
really uses the input parameter.XML is a versatile markup language, capable of labeling the information content of diverse data sources including structured and semi-structured documents, relational databases, and object repositories. A query language that uses the structure of XML intelligently can express queries across all these kinds of data, whether physically stored in XML or viewed as XML via middleware.
Property | Value |
---|---|
owned by | a triple set constructor |
trigger | evaluated once for each document in the set of input documents |
value | a sequence of nodes which is added to the union of all subject-backing nodes |
context item | an input document |
context variables | $documents: the set of all input documents |
Property | Value |
---|---|
owned by | a triple set constructor |
trigger | evaluated once |
value | used as a group key when grouping the concatenated values of {subject-provider-expression} into sets of subject-backing nodes (one set per subject) |
context item | - |
context variables | $documents: the set of all input documents |
$instance: a single node from the concatenated values of {subject-provider-expression} |
Property | Value |
---|---|
owned by | a triple set constructor |
trigger | evaluated once for each subject resource |
value | the URI of this subject |
context item | $sbn[1] (the first subject-backing node of this subject resource) |
context variables | $documents: the set of all input documents |
$sbn: subject-backing nodes of this subject resource |
Property | Value |
---|---|
owned by | a predicate descriptor |
trigger | evaluated once for each subject resource |
value | a sequence of nodes which is added to the union of all object-backing nodes for this subject resource and this predicate |
context item | $sbn[1] (the first subject-backing node of this subject resource) |
context variables | $documents: the set of all input documents |
$sbn: subject-backing nodes of this subject resource |
Property | Value |
---|---|
owned by | a predicate descriptor |
trigger | evaluated once for each subject resource |
value | used as a group key when grouping the concatenated values of {object-provider-expression} into sets of object-backing nodes (one set per object) |
context item | - |
context variables | $documents: the set of all input documents |
$sbn: subject-backing nodes of this subject resource | |
$instance: a single node from the concatenated values of {object-provider-expression} |
Property | Value |
---|---|
owned by | a predicate descriptor |
trigger | evaluated once for each subject resource (if predicate URI-valued) |
value | the URI of the object backed by $obn |
context item | $obn[1]: (the first object-backing node of this subject resource and for this predicate) |
context variables | $documents: the set of all input documents |
$obn: the object-backing nodes of this subject resource and for this predicate |
Property | Value |
---|---|
owned by | a predicate descriptor |
trigger | evaluated once for each subject resource (if predicate literal-valued) |
value | the value of the object backed by $obn |
context item | $obn[1]: (the first object-backing node of this subject resource and for this predicate) |
context variables | $documents: the set of all input documents |
$obn: the object-backing nodes of this subject resource and for this predicate |