Back to all schema formats

    Schema Formats

    XML Schema

    W3C XML Schema (XSD 1.0 and 1.1) is parsed into the MetaModel preserving complex types, substitution groups, and identity constraints — with namespace fidelity, so HL7 v2.xml, FHIR XML, and HIPAA X12-derived XSDs round-trip cleanly.

    The XSD adapter handles complex types, simple types, attribute groups, model groups, substitution groups, identity constraints (`xs:key`, `xs:keyref`, `xs:unique`), and `xs:any` wildcards. Both XSD 1.0 and XSD 1.1 (`xs:assert`, `xs:openContent`) are supported.

    Namespace declarations are preserved verbatim — including target namespaces, default namespaces, and qualified vs. unqualified element/attribute form. This is what allows HL7 v2.xml, FHIR XML, and HIPAA X12-derived XSDs to round-trip without semantic drift.

    Imported and included schemas are resolved transitively. Each `xs:import` and `xs:include` writes its own `SchemaIngested` entry, so the dependency graph between an enterprise XSD bundle and its downstream MetaModel state is reconstructable from the ledger alone.

    Restriction facets (`xs:pattern`, `xs:enumeration`, `xs:minInclusive`, `xs:maxLength`, …) become first-class annotations on the corresponding MetaModel attribute. The Visual Rules for Targets editor surfaces them as default validation rules — pre-populated, not invented.

    Every ingest writes a `SchemaIngested` entry with the importer module identifier (`XsdImporter@x.y.z`), the SHA-256 of the canonical XSD bytes, and the assigned schema ULID. Substitution-group resolution and wildcard expansion write their own `SchemaParsed` entries so a reviewer can see exactly which abstract type a concrete derivation was matched to.

    XSD support feeds directly into the FHIR and HL7-flavored Semantic Match profiles documented in NLP Heritage, where `domain_equivalence` recognizes that `Patient/identifier` in FHIR XML is the same concept as `PID-3` in HL7 v2.

    Audit ledger entries written by this capability

    Each action in this capability appends one of the following entry types to the ULID‑keyed, SHA‑256 hash‑chained audit ledger. A reviewer can replay the chain to reconstruct exactly what happened, when, and under which role.

    SchemaIngestedSchemaParsedSchemaEvolutionEvaluated
    Read the full Audit & Trust architecture

    See xml schema demonstrated against your data

    Pick a sample dataset or bring your own. We will walk the ledger from ingest through Approver release in a single working session.

    Request a demo

    Related across the platform

    Where this capability hands off — upstream adapters, downstream governance, and the underlying audit primitives.