XML Schemas (XSD)
The enaio® server-api uses XML formats for structured data exchange with the server, the structure of which is described by XML Schema Definitions (XSD).
| Schema | Description |
|---|---|
Object description for XML import jobs (Insert, Update, Delete, Copy, Move) |
|
Search requests for DMS research (GetResultList, GetDeletedObjects, stored searches) |
|
Output format for search results and object calls (GetResultList, GetObjectDetails etc.) |
|
Complete object definition of a enaio® system — cabinets, object types and fields (GetObjDef) |
1. Corrected Schema Files
At some points the XSD files as shipped by the manufacturer describe something other than what the server actually requires or sends. Queries the schema forbids are accepted by the server, and elements and attributes the schema does not know are sent by the server.
The schema files maintained with this documentation are corrected at those points against measured behaviour of enaio® server 12.0.769.25242. Every change is noted as a comment in the header of the respective file, and the individual deviations are listed with each schema:
DMSData.xsd and DMSObjDef.xsd are unchanged — no measurements are available for them.
The corrections widen the query schema rather than tighten it: bool_op remains permitted and is
merely annotated as deprecated, and previously mandatory elements become optional. One exception is
the name attribute on <Param>, which was added as a required attribute — a <Param> without a
name cannot be referenced. In the output schema DMSContent.xsd, <TxtNoticeCount> and
<PdfAnnotationCount> were added as mandatory elements because the server sends them in every
response; responses from older server versions therefore no longer validate.
A further correction does not come from a measurement but from the manufacturer documentation
itself: <Params> originally permitted a single <Param> only, although the documented examples
show queries with several parameters. The cardinality is set to maxOccurs="unbounded". The attribute
remarks on the <DMSQuery> element has been added for the same reason: the manufacturer
documentation describes it, the schema did not declare it, and the server accepts it.
The content model of <Remarks> is set against a capture with filled notes: one <Remark>
element per object note and per note link, with the child elements <Creator>, <Created>,
<Modifier>, <Modified> and <Text> including their attributes.
With these corrections the captured raw responses of the server validate unchanged against
DMSContent.xsd, and the corresponding requests against DMSQuery.xsd. The captures cover HOL
queries with child and parent objects, several <Archive> and <ObjectType> blocks per request,
cross-archive queries via <ExternalObjects>, filled notes, and a LOL response with <Rowset>
and a table field, the sql="1" output, <MultiFields> and <TypelessObjects>. The only part
not measured is a filled <Messages>; in five targeted attempts the block stayed empty.