Crate fml_xml 

XML for FHIR logical models.

FHIR maps run on JSON. Logical models whose instances are XML — CDA is the best known — say in their StructureDefinitions how the XML looks: namespaces and names, which elements are attributes or text, where xsi:type gives a type, which elements group others that appear directly in the parent. This crate reads such XML into the JSON of the model, so a map can run over it, and writes JSON of the model back as XML. It knows nothing about any particular model; everything comes from the definitions.

<value xsi:type="PQ" value="120" unit="mm[Hg]"/>   ⇄   "value": { "@type": "PQ", "value": 120, "unit": "mm[Hg]" }

The JSON form:

• property names are the model’s element names (sdtcCategory, not sdtc:category);
• attributes are primitives: boolean and numbers as JSON booleans and numbers, a repeating attribute (use="H WP") as an array;
• text content is the xmlText element, markup (narrative) a string of XML;
• a value whose type xsi:type gives, or whose type differs from the element’s, names it in "@type" (the model’s type name, IVL_TS);
• a choice group is an array of one-property objects, in document order: an address is "item": [{ "streetAddressLine": … }, { "city": … }];
• dates and times declared with a date format are read into the FHIR lexical form at the precision written (20200115093000-0500 → 2020-01-15T09:30:00-05:00) and written back the same.

Reading also records where each element was (line and column) by its path in the JSON, the path the engine’s debug trace uses, and reports what it could not read into the model instead of dropping it silently. compare tells whether two documents say the same.

Structs

Difference

A place where two documents differ.

Document

A document read from XML.

Element

An element of a type, in definition order.

Error

XML that cannot be read or written at all.

Issue

Content left out or changed while reading or writing.

Model

The types of one or more logical models, by canonical URL.

Position

A line and column in the XML, both from 1.

ReadOptions

How to read a document.

TypeDef

A type of the model: a data type or a class.

Written

XML written from JSON, and what could not be written.

Enums

IssueKind

What kind of content could not be carried over.

Representation

How an element appears in XML.

Root

What a document’s root element is: a type, or an element of a type (a fragment such as the component of a structured body, whose content is declared inline).

Constants

TYPE_KEY

The property that names the type of a value in the JSON form.

XML_NS

The xml: namespace.

XSI_NS

The XML Schema instance namespace (xsi:type).

Functions

compare

The differences between expected and actual; empty when they say the same.

compare_fragments

compare for fragments that use namespace prefixes they do not declare: both are read with namespaces in scope (see ReadOptions::namespaces).

from_compact

The FHIR-style form of a compact timestamp, or None when text is not one.

read

Reads an XML document. root_type names the type of the root element (a canonical URL or a type name); without it, the type is the one whose root element name matches.

read_with

Reads an XML document with ReadOptions.

to_compact

The compact form of a FHIR-style date or time (the inverse of from_compact); Z is written as +0000. None when text is not in that form.

write

Writes JSON of the logical model as an XML document whose root element has the type at root_type (a canonical URL or a type name). Elements are written in definition order, attributes as attributes, the "@type" of a value as xsi:type.