Import an IADS package

Ironmark imports Team-IADS .iads archives as fresh projects. TOC, DMs, graphics, DTDs, and the source dataset.xml all persist — so a later re-export produces a byte-close round-trip.

On this page — Create or pick a project · Upload the package · What happens during import · DTD retention + validation · Gotchas

Create or pick a project

Fresh import vs update

Two paths. From the Projects page, use Import IADS package on an existing project card if you're refreshing content into a known project (the "Update existing by title" checkbox on the import modal controls dedupe behavior). Otherwise create a new project and import into that.

Upload the package

Drop the .iads file

Modal accepts a Team-IADS Format A archive (XML manifest + gzip binary — IADS Viewer 4.x and later). Format B binary-header packages import too via the codec's auto-detect.

Watch the job progress

Import runs as a background job. Progress shows document counts as they land. A typical helmet-sized package (~200 files) finishes in seconds.

What happens during import

Ironmark unpacks the archive and routes each file by role:

WP XML files (Files\) — each becomes a Document. DOCTYPE is preserved; doc_type is detected from the root element and refined against the SDM manifest. source_filename is remembered so re-export ships the same basename.
Graphics (Graphics\) — land as project-scoped graphics under data/projects/<id>/graphics/. ICNs are cross-project-unique (a shared ICN across two projects doesn't collide).
DTD folder (DTD\) — preserved verbatim to data/projects/<id>/dtd/. Every file survives, including .ent, .dcf, and multiple DTD revisions.
Root dataset.xml — stashed on the project row (iads_source_dataset_xml). Re-export prefers this source over a synthesized one, patching only the known-edited fields (weapon system, dataset id, pub date, watermark).
Root toc.xml — stashed on the project row (iads_source_toc_xml). Re-export uses it to reproduce the archive's original filename plan.
Preview image (e.g. IADS.jpg) — saved and reused on export so the dataset-selection tab in IADS Viewer shows the same thumbnail.

DTD retention + validation

The DTD folder saved to data/projects/<id>/dtd/ is available for two purposes:

Round-trip export — the DTD folder ships with every IADS export from this project, so IADS Viewer validates against the same DTD your source did.
In-app validation — Ironmark auto-picks a "main" DTD (matching a WP's DOCTYPE reference where possible, else the first .dtd at the folder root) and stores its path in the project. By default, validation uses the SDM's schema entry points and falls back to the imported DTD only when no schema is found.

If your program authored against a customer-supplied DTD that differs from the SDM's default, flip Project Settings → Fallback DTD → "Use this DTD instead of the SDM's default validation". Every validation run then uses the imported DTD directly.

Skipped-files breakdown: the import job categorizes any files it didn't ingest — non-XML, unrecognized types, malformed XML, etc. — so you can see at a glance what got left out. Typical helmet-sized packages skip ~60 help images and the DTD folder (the DTD folder is "skipped as content" but saved to disk).

Gotchas

Update-existing dedupe is by title. Two DMs with the same title get merged into one Document row. Off (default) creates fresh rows.
Doc-type remapping. Some archives ship non-standard root elements (e.g. lsaDataset). Ironmark remaps to the SDM's declared docType id on import so downstream filters work.
Graphics not referenced by any DM still import — the IPD/parts flow may resolve them later, and the round-trip export needs them present.
PM / TOC / BREX files in the archive's Files\ folder don't ship as WP files on the way back out. They're project structure, not delivery content.

← All how-to guides

Import an IADS package

Create or pick a project

Fresh import vs update

Upload the package

Drop the .iads file

Watch the job progress

What happens during import

DTD retention + validation

Gotchas

Related