XSIM 3.4 · 3.3

Specification · Version 3.4

The XSIM
simulation file standard

An XML interchange format for radiological and nuclear field-exercise scenarios — instruments, sources, deposition grids, field teams, weather, and timed injects in one signed, versionable document.

A single SimFile carries a base scenario plus any number of supplemental deltas, each independently signed with XML Signature and optionally encrypted per authorization level.

Root
<SimFile>
Namespace
http://xsim.codes/xsd
3.3 alias
http://lokahi.enterprises/xsim
Types
{{ typeCount }} XSIM · {{ foreignCount }} imported
Imports
xmldsig, xenc, xenc11
Transport
UTF-8, zlib-wrapped deflate

Base plus deltas

A BaseFile holds the full scenario. Each SupplementalFile names the nodes to delete, replace, or insert by xs:ID, so updates ship as small signed patches.

Four authorization levels

Field, Oracle, Observer, and Author each unlock a different key. Field readings come only from hardware position and clock; author data stays sealed behind its own encrypted key.

Physics in the file

Efficiency curves, dead time, peak FWHM, resuspension models, and interpolated deposition grids travel with the scenario, so any conforming reader produces the same instrument response.

Validator

Runs entirely in your browser

Drop a file or paste its text and it validates immediately. Compressed documents are inflated first — zlib-wrapped deflate as written by the field library, plus gzip, raw deflate, zipped XML, and base64 envelopes. Files carrying CipherText prompt for a PasswordAuth password and are decrypted in place. Version 3.3 files are recognised by their legacy namespace. Nothing is uploaded.

{{ fileLabel }} {{ encodingLabel }}

Result

{{ profileLabel }}

{{ verdictText }}

{{ verdictMeta }}

{{ unlockHeading }}

{{ cryptoPrompt }}

{{ unlockScope }}

{{ cryptoError }}

Decrypted

{{ decryptedNote }}

{{ filterEmptyText }}

Engine scope

Content models and occurrence bounds, attribute use, simple-type facets, xsi:type substitution for abstract types, and document-wide ID/IDREF integrity — resolved across all four schemas, so signature and encryption subtrees are validated rather than skipped. An element that declares an XSD default or fixed value is reported as a warning when absent, not an error, since a conforming reader substitutes the declared value.

PasswordAuth and NoAuth sections are decrypted here — PBKDF2 to derive the key, AES-KW to unwrap it, AES-CBC and zlib to recover the contents. Signatures are verified too: canonical XML (inclusive C14N 1.0 and exclusive c14n), a recomputed digest per ds:Reference, and an RSA or ECDSA check of SignatureValue against the signing certificate — embedded in KeyInfo, or resolved from the file's TrustOnlyRoot and IntermediateCerts by issuer and serial, subject name, or id — then chained link by link to a declared trust root. All of it against the file as received, since re-indenting it changes the signed bytes. Out of scope: revocation, chains to roots the file does not carry, HMAC signatures (the secret is not in the file), and IndividualCert keys, which are wrapped with RSA v1.5 to a certificate no browser API can reach.

Known interoperability hazard

Encrypted payloads are commonly written as a zlib stream that opens with the usual 0x78 0x9C header but ends without its Adler-32 checksum. The deflate data itself is complete; only the four trailing bytes are missing.

This defeats a great many decompressors: a strict zlib reader treats the absent trailer as a truncated stream and raises an error after emitting every byte of correct output. Browser DecompressionStream('deflate'), Python zlib.decompress, Java InflaterInputStream, and Go zlib.NewReader all report corruption on a payload that decoded perfectly.

The workaround used here: skip the two-byte header and inflate the remainder as raw deflate, which carries no checksum expectation. Expect this only in files written to 3.4 and earlier — from 3.5 the trailer is required, so readers can inflate strictly. Until then, readers should not depend on it.

File summary

{{ summaryScope }}

{{ sumTitle }}

{{ sumDescription }}

{{ row.label }}
{{ row.value }}
{{ line.text }}

Authorizations

{{ a.user }} {{ a.level }} {{ a.method }}

Splash screen

{{ splashNode }}

Decoding image…

{{ splashBrokenNote }}
{{ splashCaption }}
{{ splashMatch }}
{{ splashNote }}

Contents

{{ c.n }}
{{ c.label }}

Signatures

{{ sigHeadline }}

{{ sigNote }}

{{ sig.title }} {{ sig.verdict }}
{{ sig.method }} · {{ sig.canonicalization }}
{{ sig.certs }}
{{ sig.certLine }}
{{ sig.certSource }}
{{ sig.certAdvisory }}
{{ sig.trustLine }}
{{ d.line }}
{{ sig.refs }}
{{ sig.issues }}

Certificates

{{ ci.text }}

{{ sigCaveat }}

Schema reference

Generated directly from the loaded schemas. Child lists are the effective content model — inherited particles from the extension chain are folded in, in document order. Imported ds:, xenc:, and xenc11: types are listed after the XSIM types.

{{ detailKind }}

{{ detailName }}

{{ detailLineage }}

{{ detailDoc }}

Abstract — requires xsi:type

{{ detailSubstitutes }}

Permitted values

{{ v.value }}

Pattern

{{ detailPatterns }}

Content model

{{ c.prefix }}{{ c.name }}
{{ c.occurs }}

{{ c.doc }}

Attributes

@{{ a.name }}
{{ a.type }}
{{ a.use }}

Downloads

The schema, the three W3C schemas it imports, and worked examples. Together these are everything an offline validator needs.

Schema

xsim-3.4.xsd

The normative definition, target namespace http://xsim.codes/xsd.

Example

valid.xml

A conforming scenario: two authorizations, a scalar instrument, a field team, a rain window.

Example

valid.xml.z

The same document zlib-wrapped (0x78 0x9C) with an Adler-32 trailer, as the field library writes it.

Example

invalid.xml

Ten deliberate defects — one for every class of finding the validator reports.

Example

encrypted.xml

Field data carried as AES-CBC ciphertext under a PasswordAuth authorization — PBKDF2-HMAC-SHA256, 100,000 iterations, a 128-bit key wrapped with kw-aes128. Unlock it as exercise.controller.

Password

exercise-2026

Imported W3C schemas

xmldsig-core-schema.xsd
http://www.w3.org/2000/09/xmldsig#

xenc-schema.xsd
http://www.w3.org/2001/04/xmlenc#

xenc-schema-11.xsd
http://www.w3.org/2009/xmlenc11#