zerodds-xml-compose

DDS-XML type definitions into the ZeroDDS common AST — the XML counterpart of zerodds-idl-compose.

One call takes a DDS-XML document and produces the same zerodds_ast::Ast that the IDL front end produces from an .idl file, so everything downstream of the model — zerodds_types::from_ast, the layout planner, zerodds-wire-codec, every code generator — is unchanged and does not know which language the declaration was written in.

let composed = zerodds_xml_compose::compose("types/xml/primitives.xml")?;
assert!(!composed.failed());

Why not zerodds-xml

zerodds-xml reads DDS-XML already and stops one layer short: it builds a descriptive TypeLibrary and bridges that to a MinimalTypeObject. That layer is a published API with its own users, and it drops what a model needs — for example tryConstruct, hashid and external on a member, autoid on a struct, and the int8 and uint8 primitives. This crate reuses its well-formedness layer — parse_xml_tree and its element tree, with the DDS-XML 1.0 §7.1 depth cap, element budget and namespace handling — and lowers that tree into the model itself.

What it carries

<module>, <struct> (with extensibility, baseType, autoid), <union> (with <discriminator> and <case>/<caseDiscriminator>, including default and enumerator-name labels), <enum> (with bitBound, extensibility, defaultLiteral), <bitmask> (both the <flag value=…> and <bit_value position=…> spellings), <typedef>, <forward_dcl>; every XTypes and IDL primitive spelling; bounded and unbounded strings and wstrings; sequences, maps and multi-dimensional arrays; <const> (at the top, in a module and in a structure) and <const_exp> for bounds, array dimensions and enumerator values; <include>; <bitset>; <verbatim>; <annotation> and <annotate>; and the member attributes key, optional, external, mustUnderstand, id, hashid and tryConstruct.

Member ids are assigned by DDS-XTypes 1.3 §7.3.1.2.1.1 with zerodds_idl_lower::hashed_member_id, so a type declared once in .idl and once in .xml reaches the same TypeIdentifier by construction.

What it refuses

  • <discriminator key="true"> — the model has no slot for it and UnionDiscriminatorFlag has no bit for it, so accepting it would give a keyed and an unkeyed union the same TypeIdentifier. The IDL front end refuses the same construct for the same reason.
  • <annotation baseType="…"> — the model's annotation declaration has no base.
  • A built-in annotation written as <annotate> (key, optional, …); this representation writes those as attributes (§7.3.2.5).
  • An <include> of a file that is not an XML document, and one that cannot be read.
  • Every element it does not know, in a diagnostic naming it.

Bounds

-1 is unbounded. A bound of 0 is refused (IDL takes a positive integer); ComposeOptions::zero_bound_is_unbounded reads it as unbounded, which is how the OMG dds-xtypes suite writes it.

Specification sources

  • OMG DDS-XML 1.0 (formal/18-10-01) §7.1, §7.3.3.
  • OMG DDS-XTypes 1.3 Annex A (XML Type Representation), §7.3.1.2.1.
  • OMG IDL 4.2 §7.4 where the two representations share a rule.

Position

zerodds-xml-compose

Typdefinitionen aus DDS-XML in den gemeinsamen AST von ZeroDDS — das XML-Gegenstück zu zerodds-idl-compose.

Ein Aufruf nimmt ein DDS-XML-Dokument und liefert denselben zerodds_ast::Ast, den das IDL-Frontend aus einer .idl-Datei liefert. Alles nach dem Modell — zerodds_types::from_ast, der Layoutplaner, zerodds-wire-codec, jeder Codegenerator — bleibt unverändert und weiß nicht, in welcher Sprache die Deklaration geschrieben wurde.

let composed = zerodds_xml_compose::compose("types/xml/primitives.xml")?;
assert!(!composed.failed());

Warum nicht zerodds-xml

zerodds-xml liest DDS-XML bereits und hört eine Schicht zu früh auf: Es baut eine beschreibende TypeLibrary und überführt sie in ein MinimalTypeObject. Diese Schicht ist eine veröffentlichte API mit eigenen Nutzern, und sie lässt weg, was ein Modell braucht — etwa tryConstruct, hashid und external an einem Member, autoid an einem Struct und die Primitive int8 und uint8. Diese Crate nutzt deren Schicht für Wohlgeformtheit — parse_xml_tree und seinen Elementbaum, mit der Tiefengrenze aus DDS-XML 1.0 §7.1, dem Elementbudget und der Behandlung von Namensräumen — und senkt diesen Baum selbst ins Modell ab.

Was sie abbildet

<module>, <struct> (mit extensibility, baseType, autoid), <union> (mit <discriminator> und <case>/<caseDiscriminator>, einschließlich default und Labels mit Enumerator-Namen), <enum> (mit bitBound, extensibility, defaultLiteral), <bitmask> (in beiden Schreibweisen <flag value=…> und <bit_value position=…>), <typedef>, <forward_dcl>; jede Schreibweise der Primitive aus XTypes und IDL; begrenzte und unbegrenzte Strings und Wstrings; Sequenzen, Maps und mehrdimensionale Arrays; <const> (auf oberster Ebene, in einem Modul und in einer Struktur) und <const_exp> für Grenzen, Arraydimensionen und Enumerator-Werte; <include>; <bitset>; <verbatim>; <annotation> und <annotate>; dazu die Member-Attribute key, optional, external, mustUnderstand, id, hashid und tryConstruct.

Member-IDs werden nach DDS-XTypes 1.3 §7.3.1.2.1.1 mit zerodds_idl_lower::hashed_member_id vergeben. Ein Typ, der einmal in .idl und einmal in .xml deklariert ist, erreicht so konstruktionsbedingt denselben TypeIdentifier.

Was sie ablehnt

  • <discriminator key="true"> — das Modell hat keinen Platz dafür und UnionDiscriminatorFlag kein Bit. Es anzunehmen gäbe einer Union mit und einer ohne Key denselben TypeIdentifier. Das IDL-Frontend lehnt dasselbe Konstrukt aus demselben Grund ab.
  • <annotation baseType="…"> — die Annotationsdeklaration des Modells hat keine Basis.
  • Eine eingebaute Annotation, geschrieben als <annotate> (key, optional, …); diese Darstellung schreibt sie als Attribute (§7.3.2.5).
  • Ein <include> einer Datei, die kein XML-Dokument ist, und einer, die sich nicht lesen lässt.
  • Jedes Element, das sie nicht kennt, mit einer Diagnose, die es nennt.

Grenzen

-1 bedeutet unbegrenzt. Eine Grenze 0 wird abgelehnt (IDL verlangt eine positive ganze Zahl); ComposeOptions::zero_bound_is_unbounded liest sie als unbegrenzt, so wie die OMG-Suite dds-xtypes sie schreibt.

Quellen in den Spezifikationen

  • OMG DDS-XML 1.0 (formal/18-10-01) §7.1, §7.3.3.
  • OMG DDS-XTypes 1.3 Annex A (XML Type Representation), §7.3.1.2.1.
  • OMG IDL 4.2 §7.4, wo beide Darstellungen eine Regel teilen.

Stellung