XML-Schemata (XSD)
Die enaio® server-api verwendet für den strukturierten Datenaustausch mit dem Server XML-Formate, deren Aufbau durch XML-Schema-Definitionen (XSD) beschrieben wird.
| Schema | Beschreibung |
|---|---|
Objektbeschreibung für XML-Import-Jobs (Insert, Update, Delete, Copy, Move) |
|
Suchanfragen für die DMS-Recherche (GetResultList, GetDeletedObjects, gespeicherte Suchen) |
|
Ausgabeformat für Suchergebnisse und Objektabrufe (GetResultList, GetObjectDetails u. a.) |
|
Vollständige Objektdefinition eines enaio®-Systems — Schränke, Objekttypen und Felder (GetObjDef) |
1. Korrigierte Schema-Dateien
Die vom Hersteller ausgelieferten XSD-Dateien beschreiben an einigen Stellen etwas anderes, als der Server tatsächlich verlangt oder sendet. Anfragen, die das Schema verbietet, werden vom Server akzeptiert; Elemente und Attribute, die das Schema nicht kennt, werden vom Server gesendet.
Die zu dieser Dokumentation gepflegten Schema-Dateien sind an diesen Stellen gegen gemessenes Verhalten von enaio®-Server 12.0.769.25242 korrigiert. Jede Änderung ist im Kopf der jeweiligen Datei als Kommentar vermerkt, und die einzelnen Abweichungen stehen beim jeweiligen Schema:
DMSData.xsd und DMSObjDef.xsd sind unverändert — für sie liegen keine Messungen vor.
Die Korrekturen erweitern das Anfrageschema, statt es zu verschärfen: bool_op bleibt erlaubt und
ist lediglich als veraltet annotiert, bisher zwingende Elemente werden optional. Eine Ausnahme ist
das Attribut name an <Param>, das als Pflichtattribut ergänzt wurde — ein <Param> ohne Namen
ist nicht referenzierbar. Beim Ausgabeschema DMSContent.xsd sind <TxtNoticeCount> und
<PdfAnnotationCount> als Pflichtelemente ergänzt, weil der Server sie in jeder Antwort sendet;
Antworten älterer Serverstände validieren dagegen nicht mehr.
Eine weitere Korrektur stammt nicht aus einer Messung, sondern aus der Herstellerdokumentation
selbst: <Params> ließ im Original nur ein einziges <Param> zu, obwohl die dokumentierten
Beispiele Anfragen mit mehreren Parametern zeigen. Die Kardinalität ist auf
maxOccurs="unbounded" gesetzt. Ebenso ist das Attribut remarks am <DMSQuery>-Element
ergänzt: die Herstellerdokumentation beschreibt es, das Schema deklarierte es nicht, und der
Server akzeptiert es.
Das Inhaltsmodell von <Remarks> ist gegen eine Aufnahme mit gefüllten Notizen gesetzt: ein
<Remark>-Element je Objektnotiz und je Notizverknüpfung, mit den Kindelementen <Creator>,
<Created>, <Modifier>, <Modified> und <Text> samt ihren Attributen.
Mit diesen Korrekturen validieren die aufgenommenen Roh-Antworten des Servers unverändert gegen
DMSContent.xsd und die zugehörigen Anfragen gegen DMSQuery.xsd. Die Aufnahmen decken
HOL-Abfragen mit Kind- und Elternobjekten, mehrere <Archive>- und <ObjectType>-Blöcke je
Anfrage, archivübergreifende Abfragen über <ExternalObjects>, gefüllte Notizen sowie eine
LOL-Antwort mit <Rowset> und Tabellenfeld, die sql="1"-Ausgabe, <MultiFields> und
<TypelessObjects> ab. Der einzige nicht gemessene Teil ist ein gefülltes <Messages>; in fünf
gezielten Versuchen blieb der Block leer.