Altova RaptorXML+XBRL Server 2025

In diesem Abschnitt:

•Prozessorkonformität

•Schema-Fähigkeit

•Kodierung

•Namespaces

•XML-Quelle und Validierung

•Statische und dynamische Typüberprüfung

•Bibliotheksmodule

•Externe Funktionen

•Collations

•Präzision von numerischen Daten

•Unterstützung für XQuery-Anweisungen

•Implementierungsspezifisches Verhalten

Standardkonformität

Der XQuery 1.0-Prozessor von RaptorXML+XBRL Server entspricht der XQuery 1.0 Recommendation vom 14. Dezember 2010 des W3C. Der Query-Standard stellt bei vielen Funktionen frei, wie viele diese zu implementieren sind. Im Folgenden finden Sie eine Liste, wie der Altova XQuery 1.0-Prozessor diese Funktionen implementiert.

Schema-Fähigkeit

Der Altova XQuery 1.0-Prozessor ist schemafähig.

Kodierung

Die UTF-8 und die UTF-16 Zeichen-Kodierungen werden unterstützt.

Namespaces

Die folgenden Namespace-URIs und die damit verknüpften Bindings sind vordefiniert.

Beachten Sie die folgenden Punkte:

•Der Altova XQuery 1.0-Prozessor ist so konfiguriert, dass die oben aufgelisteten Präfixe an die entsprechenden Namespaces gebunden sind.

•Da der oben angeführte Namespace für vordefinierte Funktionen (siehe fn:) der Standard-Funktions-Namespace in XQuery ist, muss beim Aufruf von vordefinierten Funktionen das Präfix fn: nicht verwendet werden (string("Hello") ruft z.B. die Funktion fn:string auf). Das Präfix fn: kann jedoch verwendet werden, um eine vordefinierte Funktion aufzurufen, ohne die Namespace im Abfrage-Prolog deklarieren zu müssen (z.B.: fn:string("Hello")).

•Sie können den Standard-Funktions-Namespace durch Deklarierung des default function namespace-Ausdrucks im Abfrageprolog ändern.

•Bei Verwendung von Typen aus dem XML Schema-Namespace kann das Präfix xs: verwendet werden, ohne dass Sie den Namespace explizit deklarieren müssen und dieses Präfix im Abfrageprolog daran binden müssen. (Beispiel: xs:date und xs:yearMonthDuration.) Wenn Sie ein anderes Präfix für den XML-Schema-Namespace verwenden möchten, muss dieses im Abfrageprolog explizit deklariert werden. (Beispiel: declare namespace alt = "http://www.w3.org/2001/XMLSchema"; alt:date("2004-10-04").)

•Beachten Sie, dass die Datentypen untypedAtomic, dayTimeDuration und yearMonthDuration mit den Candidate Recommendations vom 23 January 2007 aus dem XPath Datentypen-Namespace in den XML-Schema Namespace verschoben wurden, d.h. xs:yearMonthDuration.

Wenn Namespaces für Funktionen, Typ-Konstruktoren, Node Tests usw. falsch zugewiesen wurden, wird ein Fehler ausgegeben. Beachten Sie jedoch, dass einige Funktionen denselben Namen wie Schema-Datentypen haben, z.B. fn:string und fn:boolean. (Sowohl xs:string als auch xs:boolean ist definiert.) Das Namespace-Präfix legt fest, ob die Funktion oder der Typ-Konstruktor verwendet wird.

XML-Quelldokument und Validierung

XML-Dokumente, die bei der Ausführung eines XQuery-Dokuments mit dem Altova XQuery 1.0-Prozessor verwendet werden, müssen wohlgeformt sein. Sie müssen jedoch nicht gemäß einem XML-Schema gültig sein. Wenn die Datei nicht gültig ist, wird die ungültige Datei ohne Schemainformationen geladen. Wenn die XML-Datei mit einem externen Schema verknüpft ist und gemäß diesem Schema gültig ist, werden für die XML-Daten nachträglich Validierungsinformationen generiert und für die Auswertung der Abfrage verwendet.

Statische und dynamische Typüberprüfung

In der statischen Analysephase werden Aspekte der Abfrage überprüft wie z.B. die Syntax, ob externe Referenzen (z.B. für Module) vorhanden sind, ob aufgerufene Funktionen und Variablen definiert sind, usw. Wenn in dieser Phase ein Fehler gefunden wird, wird eine Meldung ausgegeben und die Ausführung wird gestoppt.

Die dynamische Typ-Überprüfung wird zur Laufzeit durchgeführt, während die Abfrage ausgeführt wird. Wenn ein Typ mit den Anforderungen einer Operation nicht kompatibel ist, wird ein Fehler ausgegeben. So gibt z.B. der Ausdruck xs:string("1") + 1 einen Fehler zurück, weil die Operation "Addition" nicht an einem Operanden vom Typ xs:string ausgeführt werden kann.

Bibliotheksmodule

Bibliotheksmodule dienen zum Speichern von Funktionen und Variablen, damit diese wiederverwendet werden können. Der Altova XQuery 1.0-Prozessor unterstützt Module, die in einer einzigen externen XQuery-Datei gespeichert sind. Eine solche Moduldatei muss im Prolog eine module-Deklaration enthalten, in der ein Target Namespace zugewiesen wird. Hier ein Beispielmodul:

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

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

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

Alle im Modul deklarierten Funktionen und Variablen gehören zu dem mit dem Modul verknüpften Namespace. Das Modul wird durch Import in eine XQuery-Datei mittels der import module-Anweisung im Abfrageprolog verwendet. Die import module-Anweisung importiert nur Funktionen und Variablen, die direkt in der Bibliotheksmodul-Datei deklariert sind:

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

External functions

Externe Funktionen, d.h. diejenigen Funktionen, die das Schlüsselwort external verwenden, werden nicht unterstützt:

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

Collations

Die Standard-Collation ist die Unicode Codepoint Collation, die Strings auf Basis ihrer Unicode-Codepunkte vergleicht. Andere unterstützte Collations sind die hier aufgelisteten ICU-Collations. Um eine bestimmte Collation zu verwenden, geben Sie ihre in der Liste der unterstützten Collations angeführte URI an. String-Vergleiche, wie die Funktionen fn:max und fn:min werden anhand der angegebenen Collation durchgeführt. Wenn die Collation-Option nicht definiert ist, wird die Standard-Unicode Codepoint Collation verwendet.

Präzision von numerischen Typen

•Der Datentyp xs:integer hat eine beliebige Präzision, d.h. er kann beliebig viele Stellen haben.

•Der Datentyp xs:decimal kann nach dem Dezimalpunkt maximal 20 Stellen haben.

•Die Datentypen xs:float und xs:double sind auf 15 Stellen beschränkt.

Unterstützung für XQuery-Anweisungen

Die Pragma-Anweisung wird nicht unterstützt. Gegebenenfalls wird sie ignoriert und der Fallback-Ausdruck wird evaluiert.

Implementierungsspezifisches Verhalten

Im Folgenden wird beschrieben, wie der XQuery- und der XQuery Update 1.0-Prozessor implementierungsspezifische Aspekte bestimmter Funktionen behandeln.

unparsed-text

Das Attribut href akzeptiert (i) relative Pfade für Dateien im Basis-URI-Ordner und (ii) absolute Pfade mit oder ohne das file://-Protokoll. Zusätzlich werden die folgenden (Altova-spezifischen) Kodierungen unterstützt: binarytobase16 und binarytobase64. Beispiel: xs:base64Binary(unparsed-text('chart.png', 'x-binarytobase64')).

unparsed-text-available

Das Attribut href akzeptiert (i) relative Pfade für Dateien im Basis-URI-Ordner und (ii) absolute Pfade mit oder ohne das file://-Protokoll. Zusätzlich werden die folgenden (Altova-spezifischen) Kodierungen unterstützt: binarytobase16 und binarytobase64.