The registered standard, as a plain diggs:Specification.This is the object an xlink:href into the registry resolves to, andit is bit-for-bit the same kind of object an instance document wouldotherwise have carried inline - which is the whole point of holdingit here rather than subtyping it.
<element maxOccurs="1" minOccurs="1" name="specification" type="diggs:RegisteredSpecificationPropertyType"><annotation><documentation>The registered standard, as a plain diggs:Specification. This is the object an xlink:href into the registry resolves to, and it is bit-for-bit the same kind of object an instance document would otherwise have carried inline - which is the whole point of holding it here rather than subtyping it.</documentation></annotation></element>
One or more classifications of which domain(s) of practice cite this standard - rigid inclusions, laboratory testing, in-situ testing, sampling, construction, and so on. Coded against def/docs/codes/DIGGS/0.1/specificationDomain.xml. THIS IS WHY ONE REGISTRY CAN SERVE EVERY DOMAIN. A standard cited by more than one domain - ISO 22476-4, say, cited by both rigid inclusion design and in-situ testing - carries one domain element per domain rather than being registered a second time under a different gml:id: the registry holds exactly one canonical entry per real-world standard, never two ids for the same document. domain is what a consumer or a rendering stylesheet filters and browses by, so a registry spanning every domain stays as easy to search as a single-domain one would have been. Mandatory, unlike every other metadata property on this type: an entry with no declared domain cannot be found by a domain-scoped consumer, which defeats the reason domain exists.
<element maxOccurs="unbounded" minOccurs="1" name="domain" type="gml:CodeType"><annotation><documentation>One or more classifications of which domain(s) of practice cite this standard - rigid inclusions, laboratory testing, in-situ testing, sampling, construction, and so on. Coded against def/docs/codes/DIGGS/0.1/specificationDomain.xml. THIS IS WHY ONE REGISTRY CAN SERVE EVERY DOMAIN. A standard cited by more than one domain - ISO 22476-4, say, cited by both rigid inclusion design and in-situ testing - carries one domain element per domain rather than being registered a second time under a different gml:id: the registry holds exactly one canonical entry per real-world standard, never two ids for the same document. domain is what a consumer or a rendering stylesheet filters and browses by, so a registry spanning every domain stays as easy to search as a single-domain one would have been. Mandatory, unlike every other metadata property on this type: an entry with no declared domain cannot be found by a domain-scoped consumer, which defeats the reason domain exists.</documentation></annotation></element>
Name of the organization that controls the registry entry- normally DIGGS. Distinct from the Specification's ownaccreditingBody, which names the body that publishes the STANDARD(ASTM International, BSI, CEN). Mirrorsdiggs:DefinitionType/authority.
Diagram
Type
string
Properties
content
simple
minOccurs
0
Source
<element minOccurs="0" name="authority" type="string"><annotation><documentation>Name of the organization that controls the registry entry - normally DIGGS. Distinct from the Specification's own accreditingBody, which names the body that publishes the STANDARD (ASTM International, BSI, CEN). Mirrors diggs:DefinitionType/authority.</documentation></annotation></element>
A URI for the standard itself - the publisher's landingpage or DOI - so a reader can reach the source document. Mirrorsdiggs:DefinitionType/reference. This is where the standard LIVES,not where the entry lives; the latter is the registry's owngml:identifier plus the Specification's gml:id.
Diagram
Type
anyURI
Properties
content
simple
minOccurs
0
Source
<element minOccurs="0" name="reference" type="anyURI"><annotation><documentation>A URI for the standard itself - the publisher's landing page or DOI - so a reader can reach the source document. Mirrors diggs:DefinitionType/reference. This is where the standard LIVES, not where the entry lives; the latter is the registry's own gml:identifier plus the Specification's gml:id.</documentation></annotation></element>
Lifecycle state of the registered standard. A registry must be able to say that a standard has been withdrawn or superseded WITHOUT deleting its entry, because instances published while it was current still cite it and those citations must keep resolving. ASTM D1194 is the worked example: withdrawn, but present in the historical record of plate load testing. Absent means active; state it explicitly for anything that is not.
Current and in force. The default reading when registryStatus isabsent.
enumeration
superseded
Replaced by a later standard, which should be named insupersededByRef. The entry is retained so existing citations keepresolving.
enumeration
withdrawn
Withdrawn by its publisher without a direct replacement. Retainedfor the same reason: instances published while it was current still citeit.
Source
<element minOccurs="0" name="registryStatus" type="diggs:RegistryStatusEnumType"><annotation><documentation>Lifecycle state of the registered standard. A registry must be able to say that a standard has been withdrawn or superseded WITHOUT deleting its entry, because instances published while it was current still cite it and those citations must keep resolving. ASTM D1194 is the worked example: withdrawn, but present in the historical record of plate load testing. Absent means active; state it explicitly for anything that is not.</documentation></annotation></element>
For an entry whose registryStatus is superseded or withdrawn, a reference to the Specification that replaces it - normally one registered elsewhere in the same registry. Lets a consumer follow a historical citation forward to the current standard. Points at the replacement diggs:Specification, not at its SpecificationRegistryEntry, so that following this reference yields the same kind of object as following a governingStandard. The superseding entry must appear EARLIER in the registry than the entry that cites it; DIGGS forbids forward references.
The gml:identifier value of the referenced feature, as a fully qualifiedvalue. It gives an alternative to the gml:id in xlink:href for findingthe referenced feature, mainly to reference a feature by a globallyunique identifier and where naming conflicts occur with gml:id whenaccessing data in external files.
<element minOccurs="0" name="supersededByRef" type="diggs:FeatureReferenceType"><annotation><appinfo source="urn:x-gml:targetElement">diggs:Specification</appinfo><documentation>For an entry whose registryStatus is superseded or withdrawn, a reference to the Specification that replaces it - normally one registered elsewhere in the same registry. Lets a consumer follow a historical citation forward to the current standard. Points at the replacement diggs:Specification, not at its SpecificationRegistryEntry, so that following this reference yields the same kind of object as following a governingStandard. The superseding entry must appear EARLIER in the registry than the entry that cites it; DIGGS forbids forward references.</documentation></annotation></element>
One or more diggs:Occurrence objects declaring where the registered Specification may legitimately be cited: sourceElementXpath gives the element that may hold a reference to it, and the optional conditionalElementXpath gives an element (and optionally a value) that must be present for the citation to be valid. THIS IS THE DOMAIN CHECK. Resolving an xlink:href proves only that the target exists and is a diggs:Specification; it cannot tell a rigid inclusion design basis from a laboratory sample preparation method, since both are Specifications. These declarations are what make the distinction machine-checkable, and they are read from the target's entry rather than configured into the validator - so the validator stays generic and vocabulary-independent, exactly as dictionary-validation.xsl already is for code lists. A validator that has resolved an href to a Specification inside a registry reaches these by one step up: ancestor::diggs:SpecificationRegistryEntry/diggs:occurrences. An entry with no occurrences declares no restriction, and its Specification may be cited anywhere one is permitted. Prefer stating them: an unbounded entry is the registry equivalent of an unconditioned dictionary Occurrence, and those have been a recurring source of misuse. Reuses diggs:OccurrenceArrayPropertyType from Dictionary_diggs.xsd without modification. The shape is not dictionary-specific - it is a general "this term is permitted here, conditionally on that" - and reusing it rather than inventing a parallel form is what lets one validator serve both mechanisms.
<element maxOccurs="1" minOccurs="0" name="occurrences" type="diggs:OccurrenceArrayPropertyType"><annotation><documentation>One or more diggs:Occurrence objects declaring where the registered Specification may legitimately be cited: sourceElementXpath gives the element that may hold a reference to it, and the optional conditionalElementXpath gives an element (and optionally a value) that must be present for the citation to be valid. THIS IS THE DOMAIN CHECK. Resolving an xlink:href proves only that the target exists and is a diggs:Specification; it cannot tell a rigid inclusion design basis from a laboratory sample preparation method, since both are Specifications. These declarations are what make the distinction machine-checkable, and they are read from the target's entry rather than configured into the validator - so the validator stays generic and vocabulary-independent, exactly as dictionary-validation.xsl already is for code lists. A validator that has resolved an href to a Specification inside a registry reaches these by one step up: ancestor::diggs:SpecificationRegistryEntry/diggs:occurrences. An entry with no occurrences declares no restriction, and its Specification may be cited anywhere one is permitted. Prefer stating them: an unbounded entry is the registry equivalent of an unconditioned dictionary Occurrence, and those have been a recurring source of misuse. Reuses diggs:OccurrenceArrayPropertyType from Dictionary_diggs.xsd without modification. The shape is not dictionary-specific - it is a general "this term is permitted here, conditionally on that" - and reusing it rather than inventing a parallel form is what lets one validator serve both mechanisms.</documentation></annotation></element>
Complex Type diggs:SpecificationRegistryEntryType
Namespace
http://diggsml.org/schemas/3
Annotations
Type for one registration. Extends diggs:AbstractObjectType, the standard base for DIGGS component objects, since an entry has no independent existence outside the registry that contains it. Holds the registered diggs:Specification by value, followed by the registration metadata. Every metadata property is optional except the Specification itself and its domain classification: an entry that registers nothing is meaningless, an entry with no declared domain cannot be found by a domain-scoped consumer and defeats the reason domain exists, but an entry that declares no lifecycle, authority or scope beyond that is merely unrestricted.
Database handle for the object. It is of XML type ID, so is constrained to beunique in the XML document within which it occurs. An external identifier for the object inthe form of a URI may be constructed using standard XML and XPointer methods. This is doneby concatenating the URI for the document, a fragment separator, and the value of the idattribute.
Source
<complexType name="SpecificationRegistryEntryType"><annotation><documentation>Type for one registration. Extends diggs:AbstractObjectType, the standard base for DIGGS component objects, since an entry has no independent existence outside the registry that contains it. Holds the registered diggs:Specification by value, followed by the registration metadata. Every metadata property is optional except the Specification itself and its domain classification: an entry that registers nothing is meaningless, an entry with no declared domain cannot be found by a domain-scoped consumer and defeats the reason domain exists, but an entry that declares no lifecycle, authority or scope beyond that is merely unrestricted.</documentation></annotation><complexContent><extension base="diggs:AbstractObjectType"><sequence><element maxOccurs="1" minOccurs="1" name="specification" type="diggs:RegisteredSpecificationPropertyType"><annotation><documentation>The registered standard, as a plain diggs:Specification. This is the object an xlink:href into the registry resolves to, and it is bit-for-bit the same kind of object an instance document would otherwise have carried inline - which is the whole point of holding it here rather than subtyping it.</documentation></annotation></element><element maxOccurs="unbounded" minOccurs="1" name="domain" type="gml:CodeType"><annotation><documentation>One or more classifications of which domain(s) of practice cite this standard - rigid inclusions, laboratory testing, in-situ testing, sampling, construction, and so on. Coded against def/docs/codes/DIGGS/0.1/specificationDomain.xml. THIS IS WHY ONE REGISTRY CAN SERVE EVERY DOMAIN. A standard cited by more than one domain - ISO 22476-4, say, cited by both rigid inclusion design and in-situ testing - carries one domain element per domain rather than being registered a second time under a different gml:id: the registry holds exactly one canonical entry per real-world standard, never two ids for the same document. domain is what a consumer or a rendering stylesheet filters and browses by, so a registry spanning every domain stays as easy to search as a single-domain one would have been. Mandatory, unlike every other metadata property on this type: an entry with no declared domain cannot be found by a domain-scoped consumer, which defeats the reason domain exists.</documentation></annotation></element><element minOccurs="0" name="authority" type="string"><annotation><documentation>Name of the organization that controls the registry entry - normally DIGGS. Distinct from the Specification's own accreditingBody, which names the body that publishes the STANDARD (ASTM International, BSI, CEN). Mirrors diggs:DefinitionType/authority.</documentation></annotation></element><element minOccurs="0" name="reference" type="anyURI"><annotation><documentation>A URI for the standard itself - the publisher's landing page or DOI - so a reader can reach the source document. Mirrors diggs:DefinitionType/reference. This is where the standard LIVES, not where the entry lives; the latter is the registry's own gml:identifier plus the Specification's gml:id.</documentation></annotation></element><element minOccurs="0" name="registryStatus" type="diggs:RegistryStatusEnumType"><annotation><documentation>Lifecycle state of the registered standard. A registry must be able to say that a standard has been withdrawn or superseded WITHOUT deleting its entry, because instances published while it was current still cite it and those citations must keep resolving. ASTM D1194 is the worked example: withdrawn, but present in the historical record of plate load testing. Absent means active; state it explicitly for anything that is not.</documentation></annotation></element><element minOccurs="0" name="supersededByRef" type="diggs:FeatureReferenceType"><annotation><appinfo source="urn:x-gml:targetElement">diggs:Specification</appinfo><documentation>For an entry whose registryStatus is superseded or withdrawn, a reference to the Specification that replaces it - normally one registered elsewhere in the same registry. Lets a consumer follow a historical citation forward to the current standard. Points at the replacement diggs:Specification, not at its SpecificationRegistryEntry, so that following this reference yields the same kind of object as following a governingStandard. The superseding entry must appear EARLIER in the registry than the entry that cites it; DIGGS forbids forward references.</documentation></annotation></element><element maxOccurs="1" minOccurs="0" name="occurrences" type="diggs:OccurrenceArrayPropertyType"><annotation><documentation>One or more diggs:Occurrence objects declaring where the registered Specification may legitimately be cited: sourceElementXpath gives the element that may hold a reference to it, and the optional conditionalElementXpath gives an element (and optionally a value) that must be present for the citation to be valid. THIS IS THE DOMAIN CHECK. Resolving an xlink:href proves only that the target exists and is a diggs:Specification; it cannot tell a rigid inclusion design basis from a laboratory sample preparation method, since both are Specifications. These declarations are what make the distinction machine-checkable, and they are read from the target's entry rather than configured into the validator - so the validator stays generic and vocabulary-independent, exactly as dictionary-validation.xsl already is for code lists. A validator that has resolved an href to a Specification inside a registry reaches these by one step up: ancestor::diggs:SpecificationRegistryEntry/diggs:occurrences. An entry with no occurrences declares no restriction, and its Specification may be cited anywhere one is permitted. Prefer stating them: an unbounded entry is the registry equivalent of an unconditioned dictionary Occurrence, and those have been a recurring source of misuse. Reuses diggs:OccurrenceArrayPropertyType from Dictionary_diggs.xsd without modification. The shape is not dictionary-specific - it is a general "this term is permitted here, conditionally on that" - and reusing it rather than inventing a parallel form is what lets one validator serve both mechanisms.</documentation></annotation></element></sequence></extension></complexContent></complexType>