Schema for DIGGS Specification Registries.
A specification registry is a standalone, authority-controlled document holding one
canonical diggs:Specification per published standard - an ASTM or AASHTO method, a
national or European standard, an agency special provision - so that a data provider
cites a standard by reference rather than retyping its bibliographic details into every
instance document. It is an authority artifact of the same kind as a code list
dictionary, NOT project data: registries are published and versioned by DIGGS (or
another named authority), never assembled inside a project's own instance document.
WHY THIS EXISTS. diggs:Specification's own documentation (core/Common.xsd) states that
it "exists to CITE a published standard - its properties are standardReferenceNumber,
standardTitle, standardVersion and so on - and it states no requirement of its own."
Until now there was nowhere to put a canonical one, so every provider inlined their own,
and the same standard was described a dozen different ways. That variation is what a
registry removes.
THE CENTRAL DESIGN CONSTRAINT: A REFERENCE RETURNS EXACTLY WHAT AN INLINE VALUE WOULD.
Almost every xlink:href in DIGGS resolves to the same object a consumer would have found
inline - most urn:x-gml:targetElement declarations name a CONCRETE element
(diggs:Project, diggs:Sample, diggs:Equipment, and diggs:Specification itself), not an
abstract head. A receiving application that resolves diggs:governingStandard has always
found a diggs:Specification there, and must continue to.
So the registry does NOT extend or subtype diggs:Specification, and does not introduce
any new element that could appear where a Specification is expected. It holds PLAIN
diggs:Specification objects, unchanged and unwrapped, exactly as an instance document
would carry them. An earlier draft of this schema defined a RegisteredSpecification
substituting diggs:Specification; that was withdrawn precisely because it would have
handed consumers an object of a type they had never seen at that position.
The registry metadata therefore lives on a SEPARATE object -
diggs:SpecificationRegistryEntry - which contains the Specification it registers. This
is also the more honest modelling: registryStatus, authority and occurrences are facts
about the REGISTRATION, not about the standard. Whether ASTM has withdrawn a method is a
property of the standard's lifecycle as DIGGS catalogues it; it is not one of the
bibliographic properties that identify the document.
HOW A CITATION IS VALIDATED. Every property typed diggs:SpecificationPropertyType
carries gml:AssociationAttributeGroup, so an instance may write
<governingStandard xlink:href="https://diggsml.org/def/registry/DIGGS/0/specifications.xml#astm_d1143"/>
with no schema change of any kind, and the href resolves to a plain diggs:Specification.
Validation of that reference has two layers, and both reuse machinery that already
exists:
1. TARGET CLASS - the citing element carries
<appinfo source="urn:x-gml:targetElement">, the established DIGGS convention (46 uses
across the schema; diggs:AbstractAcceptanceCriterionType/sourceSpecRef already names
diggs:Specification this way). Because a registry holds plain Specifications, that
declaration is satisfied directly - no substitution reasoning required of the consumer
or the validator.
2. TARGET APPLICABILITY - the question "is this citing element allowed to cite THIS
standard?" is answered by the diggs:occurrences property on the registry ENTRY, reusing
diggs:OccurrenceArrayPropertyType from Dictionary_diggs.xsd unchanged. Having resolved
an href to a diggs:Specification inside a registry, a validator reaches the governing
declarations by one deterministic step up:
ancestor::diggs:SpecificationRegistryEntry/diggs:occurrences
An entry declares the XPath(s) at which its Specification may legitimately be cited, so
a laboratory sample preparation standard cannot be cited as a rigid inclusion design
basis. This is the identical mechanism, in the identical shape, that
dictionary-validation.xsl already applies to a code list Definition - the constraint
travels with the registered term, so the validator stays generic and never needs
per-domain knowledge or a lookup table.
The one asymmetry with a code list is deliberate: a dictionary carries occurrences ON
the object the codeSpace resolves to, whereas a registry carries them one level above
the object the href resolves to. That single extra step is internal to the validator and
costs nothing; keeping the href's return type stable is worth far more, because it
affects every receiving application rather than one XSL module.
SCOPE. ONE UNIFIED REGISTRY, NOT ONE PER DOMAIN. An earlier draft of this schema scoped
each registry document to a single domain, mirroring how def's dictionaries are already
organized by domain prefix (gp_, pil_, mwd_, cpt_, gr_inj_, ri_design_). That was
withdrawn: a standard is routinely cited by more than one domain (ISO 22476-4 by both
rigid inclusion design and in-situ testing; EN 12699/EN 14679 by both rigid inclusion
design and construction execution), and per-domain files would have forced a choice
between registering the same real-world standard twice under two different gml:ids - the
exact ambiguity a registry exists to remove - or an arbitrary, undiscoverable "home" file
for a cross-cutting standard. diggs:SpecificationRegistryEntry/diggs:domain
(below) carries the classification instead: one registry, one entry per standard, one or
more domain codes per entry. A rendering stylesheet filters by domain for browsability;
the schema itself does not partition by it.
|