This describes the status of the Qexo version 1.9.1.
Qexo 1.9.1 implements most of the core XQuery specification, and passes over 98% of the XQuery Test Suite.
Qexo implements the Full Axis Feature.
Qexo implements the Module Feature.
Qexo implements the Serialization Feature. However, only some serialization parameters are settable.
Qexo does not implement the Schema Import Feature.
Qexo does not implement the Schema Validation Feature.
Qexo implements some ad-hoc static typing, but does not implement Static Typing Feature.
xs:untypedAtomic is implemented using gnu.kawa.xml.UntypedAtomic.
xs:dateTime, xs:date, xs:time,
xs:gYearMonth, xs:gYear, xs:gMonthDay, xs:gDay, and xs:gMonth
are implemented using gnu.math.DateTime.
xs:duration, xs:yearMonthDuration,
xs:dayTimeDuration are implemented using gnu.math.Duration.
xs:QName is implemented using gnu.mapping.Symbol.
xs:boolean is implemented using java.lang.Boolean.
xs:string is implemented using java.lang.String. The interface java.lang.CharSequence is the type for
xs:string and its subtypes.
xs:normalizedString, xs:token,
xs:language, xs:NMTOKEN, xs:Name,
xs:NCName, xs:ID, xs:IDREF,
and xs:ENTITY are implemented using gnu.kawa.xml.XString.
xs:integer, xs:positiveInteger,
xs:nonPositiveInteger, xs:negativeInteger,
and xs:nonNegativeInteger are implemented using gnu.math.IntNum.
xs:long, xs:int, xs:short, xs:byte, xs:unsignedLong, xs:unsignedInt, xs:unsignedShort, xs:unsignedbyte are currently also implemented
using gnu.math.IntNum, but in the future may be implemented using primitive Java types.
xs:decimal is implemented using java.math.BigDecimal.
xs:base64Binary is implemented using gnu.kawa.xml.Base64Binary.
xs:hexBinary is implemented using gnu.kawa.xml.HexBinary.
xs:anyURI is implemented using gnu.text.Path and specifically gnu.text.URIPath.
xs:NOTATION is implemented using
gnu.kawa.xml.Notation.
Except as noted below, all XQuery expression forms are handled.
ordered, unordered expressions are
recognized but ignored.
validate expressions are not supported.
Extension expressions are implemented, but no extensions are currently recognized.
VersionDecl (xquery version) is handled
but any encoding specification is ignored.
VarDecl (declare variable): Ok, including
support for external variables.
FunctionDecl (declare function): Ok, though no
support for external functions yet.
Type conversion and casting behavior are uneven:
the special function conversions (such as atomization) are
not done for non-builtin functions.
NamespaceDecl (declare namespace): Ok.
DefaultNamespaceDecl (declare default (element/function) namespace): Ok.
BoundarySpaceDecl (declare boundary-space): Ok.
DefaultCollationDecl (declare default collection): Ok. The default collection is set in the static context, but so far
nothing uses it. Also, only the default (code-point) collation works.
BaseURIDecl (declare base-uri): Ok.
ConstructionDecl (declare construction): Not implemented.
OrderingModeDecl (declare ordering): Ok.
EmptyOrderDecl (declare default oder empty): Ok.
CopyNamespacesDecl (declare copy-namespaces): Ok.
SchemaImport (import scheme): Not implemented.
ModuleImport (module import): Works, including support for separate compilation.
OptionDecl (declare option): Ok, though
there are no options handled yet.
These should all work correctly.
Note that nilled always returns false, since Qexo doesn't do validation.
Ok.
Ok.
These should all work correctly.
These should all work correctly.
These generally work correctly. A few of the functions do not support an optional collation argument.
Strings can contain characters outside the Unicode 16-bite base plane,
and most operations correctly handle such characters using surrogate pairs.
This means that an operation like string-length
has to scan the string to see if there are any surrogate characters,
rather than using the Java String.length() method.
Some of the regex functions require JDK 1.5 or better to correctly
handle surrogate charscters.
The regular expression (pattern patching) functions use
the Java java.util.regex classes. These recognize
a pattern syntax which is close to but not identical to that
required by the Schema specification.
normalize-unicode only works
if Kawa has been configured and built with --select-java6.
These should all work correctly.
These should all work correctly.
These are all implememented and should work correctly.
There a few edge cases not quite right, because we use
java.util.Calendar in the implementation of the date and time
classes, and Calendar doesn't completely match
our needs.
These should all work correctly.
base64Binary and hexBinaryThese should all work correctly.
NOTATIONThis (i.e. op:NOTATION-equal) should work correctly.
These should all work correctly.
These generally work fine, expect:
deep-equal does not take collation into account,
and there are probably some other data types not handled quite correctly.
id works and automatically generates an efficient index the
first time it is called. However, because Qexo does not do validation,
only attributes named xml:id are recognzied as having
the is-id property.
idref always returns the empty sequence.
These should all work.
These should all work.