Attribute-context resolution
An attribute’s tag, VR, and VM are registry facts. Its requiredness comes from how PS3.3 uses it in a module, macro, functional group, or IOD.
The contextual resolver brings those layers together.
Inputs
Section titled “Inputs”A request identifies:
- an attribute by tag, keyword, or name;
- a concrete edition;
- an IOD or SOP Class context.
A SOP Class is resolved through imported PS3.4 links to one or more IODs.
Resolution path
Section titled “Resolution path”attribute input -> PS3.6 data element -> selected IOD context -> applicable module and macro paths -> matching attribute-use rows -> declared types and condition text -> bounded effective-type analysisEvery layer retains source references.
Declared type versus effective type
Section titled “Declared type versus effective type”A declared type belongs to one imported attribute-use row.
An effective type is a resolver result for the selected context after comparing all applicable uses and bounded override language.
These are not interchangeable.
Single-use result
Section titled “Single-use result”When one applicable use remains, its declared type can be reported as the effective type.
The response still retains the use row and its source reference.
Multiple-use result
Section titled “Multiple-use result”When multiple uses apply, the resolver evaluates the DICOM lowest-type rule and inspects matched descriptions and condition text for explicit type override phrases.
A deterministic phrase such as “shall be Type 1” can override the base comparison when it is linked to the applicable use and source reference.
Ambiguity is preserved
Section titled “Ambiguity is preserved”The resolver leaves effective_type null when:
- applicable rows conflict;
- override language is ambiguous;
- an override cannot be linked uniquely;
- required context is missing;
- graph resolution leaves multiple incompatible paths.
Warnings explain the boundary. The correct downstream behavior is to inspect the cited source, not to guess.
Conditions are not all machine decidable
Section titled “Conditions are not all machine decidable”A condition can depend on:
- values in a particular instance;
- implementation choices;
- acquisition or modality state;
- relationships not represented by the current query input;
- prose semantics too broad for a deterministic parser.
That is why contextual responses are classified as partially decidable even when an effective type is returned.
Design consequence for validators
Section titled “Design consequence for validators”A validator can use the resolver to identify candidate requirements and source rules. It still needs instance context and implementation logic to evaluate many conditional requirements.
The project supports validation workflows; it does not provide official conformance certification.