Skip to content

Parser and query coverage

Coverage has three separate meanings:

  1. a DocBook part is acquired and its generic structure is persisted;
  2. a part-specific parser imports semantic records;
  3. a public resolver exposes those records as a supported query.

Do not infer the third from the first two.

Part Structured records in the documented source state Dedicated public query surface Cited text
PS3.3 IODs, modules, macros, module uses, functional-group uses, attribute uses, include rows, conditions, contextual value-term links IOD lookup, IOD modules, module attributes, contextual attribute resolution, contextual value-term lookup Yes
PS3.4 Service/SOP Class records and SOP-Class-to-IOD links SOP Class lookup and SOP-context resolution Yes
PS3.5 VR definitions and Transfer Syntax encoding details VR lookup, Transfer Syntax lookup, encoding explanation Yes
PS3.6 Data-element registry and UID registry Data-element lookup, UID lookup; registry facts also support other resolvers Yes
PS3.7 Generic document structure and selected message/service parsing used by build diagnostics No general dedicated PS3.7 structured lookup tool Yes
PS3.8 Generic document structure and selected networking parsing used by build diagnostics No general dedicated PS3.8 structured lookup tool Yes
PS3.10 File-meta requirement records and DICOM media-type records Media-type lookup; no general public file-meta requirement tool Yes
PS3.16 SR templates and rows, context groups and rows, locally derived coded concepts SR template, context group, and code-meaning lookup Yes
PS3.18 DICOMweb transactions, routes, constraints, status codes, and media-type records DICOMweb transaction and media-type lookup Yes

Only parts present as DocBook XML in the selected source manifest can be parsed for that build.

Some public results combine more than one part:

  • Transfer Syntax lookup joins PS3.6 UID identity with PS3.5 encoding details.
  • SOP Class lookup joins PS3.4 records with PS3.3 IODs.
  • Contextual attribute resolution combines PS3.6 data-element identity, PS3.3 graph paths, and optionally PS3.4 SOP Class context.
  • Media-type results can represent PS3.10 and PS3.18 service contexts.
  • Value-term lookup links generic parsed variable lists to PS3.6 elements and PS3.3 attribute-use context when deterministic links are available.

The response’s references reveal the parts used.

The importer recognizes parsed variable lists whose titles contain Enumerated Values or Defined Terms.

It attempts deterministic association through surrounding section title, anchor, tag, keyword, prose, and existing attribute-use context. When one unique association is not available, the result can remain unlinked or ambiguous rather than forcing a match.

PS3.3 module queries preserve include rows. Optional expansion works only for resolved imported macro relationships. Unresolved includes contribute to build metrics and warnings.

Condition text and normalized condition records are stored where parsed. Contextual effective-type computation recognizes bounded explicit type override patterns.

The project does not claim complete machine interpretation of arbitrary conditional prose.

Every loaded DocBook part contributes persisted sections and text suitable for:

  • part-filtered SQLite FTS search;
  • bounded retrieval by section or anchor;
  • official-reference generation.

Text availability is broader than specialized query coverage, but text responses have explanatory evidence classification and low parse confidence.

This matrix does not imply:

  • every table or prose rule in the named parts has a semantic parser;
  • every cross-reference resolves;
  • every template or condition can be fully expanded and decided;
  • a partial build can answer cross-part questions;
  • a successful query certifies an implementation;
  • the project redistributes the parsed standard.

Use build metrics, per-part warnings, official-edition integration tests, and returned references to assess a specific local build.