Commit 3ba33d6f authored by mrodzis's avatar mrodzis 🌎
Browse files

update Schematron IDs to avoid ID conflicts

parent eaff3241
......@@ -40,7 +40,7 @@
taken from a (local) controlled vocabulary. This should improve the interoperability of the data and recall rates
in aggregating web services.</sch:p>
<sch:rule abstract="true" id="MixedContentInfo">
<sch:rule abstract="true" id="sch_MixedContentInfo">
<sch:report
test="text()[matches(., '[\w]')]" role="info">
In upcoming versions of LIDO <sch:name/> will only allow for skos:Concept, lido:conceptID and lido:term as child elements.
......@@ -55,7 +55,7 @@
This isn't stated clearly in the LIDO v1.0 schema documentation but should be kept in mind when indexing objects; otherwise the preferred
variant might be unclear to a data user. Also, omitting this attribute contradicts international best practices for retrieval quality.</sch:p>
<sch:rule abstract="true" id="pref">
<sch:rule abstract="true" id="sch_pref">
<sch:let name="current" value="current()"/>
<sch:let name="currentName" value="$current/name()"/>
<sch:let name="parent" value="$current/.."/>
......@@ -76,7 +76,7 @@
<sch:title>@pref: "alternative" instead of "alternate"</sch:title>
<sch:p>LIDO v1.0 falsely suggests the value 'alternate' for the pref attribute. It is established to use 'alternative' in this context.</sch:p>
<sch:rule abstract="true" id="alternate">
<sch:rule abstract="true" id="sch_alternate">
<sch:report test="@lido:pref = 'alternate'" role="warn">
It is established to use 'alternative' instead of 'alternate' in this context. Consider changing the attribute's value or using the corresponding
LIDO terminology, http://terminology.lido-schema.org/pref and http://terminology.lido-schema.org/alternative, instead.
......@@ -89,7 +89,7 @@
<sch:p>Check if a given string complies to the ISO 8601 date convention. This pattern is used for
the cases where an element allows for xs:string in LIDO v1.0 while providing a date.</sch:p>
<sch:rule abstract="true" id="DateTime">
<sch:rule abstract="true" id="sch_DateTime">
<sch:assert role="warn" test="matches(., '-?[0-9]{4}-(0[1-9]|1[12])-([0][1-9]|[12][0-9]|3[01])T([01][0-9]|2[0-3])(:[0-5][0-9]){2}(Z|(\+|\-)(0[0-9]|1[12])(:[0-5][0-9])?)')">
The date provided in <sch:name/> should comply to the format [-]CCYY-MM-DDThh:mm:ss[Z|(+|-)hh:mm].
</sch:assert>
......@@ -113,7 +113,7 @@
<sch:p>IIIF resources provide information about their measurements in their
info.json. Therefore it is redundant to also make the resource's measurements
available in lido:resourceMeasurementsSet.</sch:p>
<sch:rule context="lido:resourceRepresentation" id="IIIF_Measurements">
<sch:rule context="lido:resourceRepresentation" id="sch_IIIF_Measurements">
<sch:assert role="warn"
test="
(@type = 'http://terminology.lido-schema.org/lido00911' or @type = 'http://terminology.lido-schema.org/lido00912')
......
This diff is collapsed.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment