Deployed 590aba6 to dev with Zensical 0.0.57 and mike 2.2.0+zensical-0.1.0

Author: github-actions[bot]

dev/guide/meta-schema/index.html

@@ -1226,10 +1226,6 @@ <h1 id="meta-schema-vocabulary">Meta-schema &amp; Vocabulary<a class="headerlink
 <td>Names of reverse properties that are required.</td>
 </tr>
 <tr>
-<td><code>x-oold-reverse-default-properties</code></td>
-<td>Deprecated. Names of reverse properties shown by default in generated user interfaces. Like the object-level defaultProperties array this is extend-only under composition; prefer a per-reverse-property x-oold-ui-default-property boolean, which is overridable.</td>
-</tr>
-<tr>
 <td><code>@context</code></td>
 <td></td>
 </tr>

dev/meta/oold-meta-schema-base.json

@@ -235,14 +235,6 @@
       "type": "array",
       "items": { "type": "string" },
       "examples": [["SI base unit of length", "SI base unit of time"]]
-    },
-    "x-oold-reverse-default-properties": {
-      "description": "Deprecated. Names of reverse properties shown by default in generated user interfaces. Like the object-level defaultProperties array this is extend-only under composition; prefer a per-reverse-property x-oold-ui-default-property boolean, which is overridable.",
-      "deprecated": true,
-      "type": "array",
-      "items": {
-        "type": "string"
-      }
     }
   }
 }

dev/search.json

@@ -1087,7 +1087,7 @@ <h2>Terminology</h2>
 <span class="rule" id="OOLD-EXT-2b61" tabindex="0" role="link" title="OOLD-EXT-2b61 - A compact-IRI prefix used by a property must be defined in the @context.">- <strong>Compact form specifically</strong> - a <code>&quot;pattern&quot;</code> such as <code>&quot;^[A-Za-z_][\\w.-]*:(?!//)\\S*$&quot;</code>, which accepts <code>ex:alice</code> and <code>schema:Person</code> while rejecting <code>http://…</code>; the prefix <em class="rfc2119">MUST</em> be defined in the <code>@context</code>.</span></li>
 </ul></section><section id="value-term-aliases"><h5>Value-term aliases (<code>@vocab</code>)</h5><p>The <a href="#synonyms">synonym machinery</a> keys <code>x-oold-context</code> by <em>term</em>, so it reaches property and class terms but not IRIs that appear as instance <em>values</em> - for example the unit IRIs a quantity property points at, where two widely used unit vocabularies name the same unit differently: QUDT <code>http://qudt.org/vocab/unit/SEC</code> and the <a href="https://github.com/HajoRijgersberg/OM">Ontology of units of Measure</a> <code>http://www.ontology-of-units-of-measure.org/resource/om-2/second</code>. Coercing the property with <code>&quot;@type&quot;: &quot;@vocab&quot;</code> (rather than <code>&quot;@type&quot;: &quot;@id&quot;</code>) closes the gap: a string value is then resolved against the active context's terms before the base IRI, so declaring the unit as a value term (<code>&quot;second&quot;: &quot;http://qudt.org/vocab/unit/SEC&quot;</code>) lets an instance write the readable <code>&quot;second&quot;</code> while the same <code>x-oold-context</code> synonyms and profile selection alias it (<code>&quot;x-oold-context&quot;: { &quot;second&quot;: { &quot;om:second&quot;: { … } } }</code>); full IRIs remain valid values. Individual mappings round-trip through SSSOM like any other.</p>
 <p>Because <code>@vocab</code> expands an unmatched string against the vocabulary - concatenating it onto the default vocabulary base when one is set (minting a new IRI), or leaving it a relative IRI when none is - a typo silently becomes a stray IRI rather than an error. <span class="rule" id="OOLD-EXT-fdd8" tabindex="0" role="link" title="OOLD-EXT-fdd8 - A property coerced @type @vocab should constrain its values with an enum or x-oold-range.">A property coerced <code>&quot;@type&quot;: &quot;@vocab&quot;</code> therefore <em class="rfc2119">SHOULD</em> constrain its values with an <code>enum</code> of the value terms (optionally named with <code>x-enum-varnames</code>) or with <code>x-oold-range</code>, so only intended individuals are accepted.</span> <span class="rule" id="OOLD-EXT-2542" tabindex="0" role="link" title="OOLD-EXT-2542 - Value terms should not collide with JSON-LD keyword aliases or other context terms.">The value terms <em class="rfc2119">SHOULD</em> also be kept from colliding with JSON-LD keyword aliases (<code>id</code>, <code>type</code>) or other context terms, since a value term shares the context's global term namespace - a term added for a value would otherwise also rewrite a property or keyword of the same name.</span> Confining the value terms to the property's own scoped <code>@context</code> keeps them out of that shared namespace, since they then resolve only for that property's values; naming them with opaque identifiers such as UUIDs avoids the clash where readability is not required.</p></section><section id="why-x-oold-ref"><h5>Why <code>x-oold-ref</code> and not <code>$ref</code></h5><p><code>x-oold-range</code> is a custom keyword, so a <code>$ref</code> placed inside it is undefined behavior for generic JSON Schema tooling ([[JSONSCHEMA]] §9.4.2). In practice the behavior is not merely undefined but inconsistent: generic reference resolvers eagerly inline such a <code>$ref</code>, and because <code>x-oold-range</code> targets can form a cyclic graph of schemas this can pull in an unbounded graph, while schema-aware bundlers instead drop it.</p>
-<p><code>x-oold-ref</code> avoids this. Generic tools only follow the standard <code>$ref</code> keyword, so they leave <code>x-oold-ref</code> untouched. <span class="rule" id="OOLD-EXT-6007" tabindex="0" role="link" title="OOLD-EXT-6007 - An OO-LD-aware tool resolves x-oold-ref lazily and handles a cyclic reference graph by terminating rather than recursing indefinitely.">An OO-LD-aware tool <em class="rfc2119">SHOULD</em> resolve <code>x-oold-ref</code> lazily, and <em class="rfc2119">MUST</em> handle a cyclic reference graph - terminating and returning the references it has already resolved, rather than recursing indefinitely - since the graph it opts into may be unbounded or self-referential.</span> The standard <code>$ref</code> continues to be used for ordinary schema composition (<code>allOf</code>, <code>properties</code>, <code>$defs</code>), which bundlers are expected to resolve. Because the only difference is the keyword name, the mapping is reversible: an OO-LD-aware tool can mechanically replace <code>x-oold-ref</code> with <code>$ref</code> to obtain a plain, fully-resolvable JSON Schema - the explicit opt-in to resolving the (possibly cyclic) graph.</p></section><section id="range-generation-targets" class="informative"><h5>Generation targets</h5><p><code>x-oold-range</code> (and the reverse properties below) exist so that the logical and conceptual modelling layers can be generated from the same OO-LD source instead of being maintained separately: a range constrains the type of a referenced object, which an OO-LD-aware tool emits as a <a href="https://www.w3.org/TR/shacl/">SHACL</a> property shape (<code>sh:class</code> / <code>sh:node</code>) and as an OWL property restriction. <a href="https://www.w3.org/TR/shacl12-core/">SHACL 1.2</a> (in progress, including Node Expressions for derived values) and OWL are the intended targets. These are generation targets, not additional validation performed by generic JSON Schema tools.</p></section></section><section id="reverse-properties"><h4>Reverse properties</h4><p>Many relations are symmetric (e.g. Organization employs Person ⇔ Person works for Organization) and users want to edit them from both sides, without storing the information twice. The keywords <code>x-oold-reverse-properties</code> and <code>x-oold-reverse-required</code> declare such a [=reverse property=], mapped with JSON-LD <code>@reverse</code> in the <code>@context</code>. (The earlier <code>x-oold-reverse-default-properties</code> array is deprecated: mark a reverse property shown by default with <code>x-oold-ui-default-property</code> on the property itself - see <a href="#ui-generation"></a> - which, unlike the merged array, is overridable under composition.) To make <code>employees</code> the reverse of <code>works_for</code>:</p>
+<p><code>x-oold-ref</code> avoids this. Generic tools only follow the standard <code>$ref</code> keyword, so they leave <code>x-oold-ref</code> untouched. <span class="rule" id="OOLD-EXT-6007" tabindex="0" role="link" title="OOLD-EXT-6007 - An OO-LD-aware tool resolves x-oold-ref lazily and handles a cyclic reference graph by terminating rather than recursing indefinitely.">An OO-LD-aware tool <em class="rfc2119">SHOULD</em> resolve <code>x-oold-ref</code> lazily, and <em class="rfc2119">MUST</em> handle a cyclic reference graph - terminating and returning the references it has already resolved, rather than recursing indefinitely - since the graph it opts into may be unbounded or self-referential.</span> The standard <code>$ref</code> continues to be used for ordinary schema composition (<code>allOf</code>, <code>properties</code>, <code>$defs</code>), which bundlers are expected to resolve. Because the only difference is the keyword name, the mapping is reversible: an OO-LD-aware tool can mechanically replace <code>x-oold-ref</code> with <code>$ref</code> to obtain a plain, fully-resolvable JSON Schema - the explicit opt-in to resolving the (possibly cyclic) graph.</p></section><section id="range-generation-targets" class="informative"><h5>Generation targets</h5><p><code>x-oold-range</code> (and the reverse properties below) exist so that the logical and conceptual modelling layers can be generated from the same OO-LD source instead of being maintained separately: a range constrains the type of a referenced object, which an OO-LD-aware tool emits as a <a href="https://www.w3.org/TR/shacl/">SHACL</a> property shape (<code>sh:class</code> / <code>sh:node</code>) and as an OWL property restriction. <a href="https://www.w3.org/TR/shacl12-core/">SHACL 1.2</a> (in progress, including Node Expressions for derived values) and OWL are the intended targets. These are generation targets, not additional validation performed by generic JSON Schema tools.</p></section></section><section id="reverse-properties"><h4>Reverse properties</h4><p>Many relations are symmetric (e.g. Organization employs Person ⇔ Person works for Organization) and users want to edit them from both sides, without storing the information twice. The keywords <code>x-oold-reverse-properties</code> and <code>x-oold-reverse-required</code> declare such a [=reverse property=], mapped with JSON-LD <code>@reverse</code> in the <code>@context</code>. A reverse property shown by default in a generated user interface is marked with <code>x-oold-ui-default-property</code> on the property itself (see <a href="#ui-generation"></a>). To make <code>employees</code> the reverse of <code>works_for</code>:</p>
 <ul>
 <li>define <code>works_for</code> in the <code>properties</code> of <code>Person</code>, mapped to a semantic property (<code>schema:worksFor</code>) in the <code>@context</code> of <code>Person</code>;</li>
 <li>define <code>employees</code> in <code>x-oold-reverse-properties</code> of <code>Organization</code>, mapped with <code>@reverse</code> to the same property in the <code>@context</code> of <code>Organization</code> ([[JSON-LD11]] reverse properties).</li>
@@ -1361,7 +1361,7 @@ <h2>Terminology</h2>
 </table>
 <p>The text-valued keywords have a <code>x-oold-multilang-*</code> variant carrying a BCP-47 language map, mirroring <code>x-oold-multilang-title</code> (see <a href="#localizing-schema-annotations"></a>): <code>x-oold-multilang-ui-hint</code> and <code>x-oold-multilang-ui-enum-titles</code>.</p>
 <p><code>x-oold-ui-enum-titles</code> holds human display labels for a form, and is distinct from the code-generation keywords <code>x-enum-varnames</code> and <code>x-enum-descriptions</code>, which are specified in <a href="#enum-names"></a>.</p>
-<p><code>x-oold-ui-default-property</code> replaces the json-editor <code>defaultProperties</code> array (which listed the optional properties shown initially). That array is <em>extend-only</em> under composition: because composed schemas merge the arrays, a derived schema can add a default property but cannot switch one off. A per-property boolean is <em>overridable</em> - it resolves most-derived-wins (see <a href="#merge-and-override-model"></a>), so a derived schema sets it to <code>false</code> to hide a property a base schema showed. For the same reason <code>x-oold-reverse-default-properties</code> is deprecated in favour of <code>x-oold-ui-default-property</code> on the reverse property.</p></section><section id="widget-hints"><h5>Widget hints: <code>format</code> vs <code>x-oold-ui-widget</code></h5><p><code>format</code> carries the widget hint when its value is a registered JSON Schema 2020-12 format (<code>date</code>, <code>date-time</code>, <code>time</code>, <code>duration</code>, <code>email</code>, <code>uri</code>, <code>iri</code>, <code>uuid</code>, ...); a validator may check it and a form generator picks the matching input. <span class="rule" id="OOLD-EXT-1e3c" tabindex="0" role="link" title="OOLD-EXT-1e3c - A widget hint that is not a registered format goes in x-oold-ui-widget, leaving format for validation.">A value that is not a registered format (<code>table</code>, <code>tabs</code>, <code>grid</code>, <code>autocomplete</code>, <code>textarea</code>, <code>checkbox</code>, <code>markdown</code>, <code>color</code>, ...) is widget-only and <em class="rfc2119">MUST</em> be carried in <code>x-oold-ui-widget</code> rather than <code>format</code>, which stays a validation assertion: a validator that checks declared formats would otherwise reject every value of the property.</span></p></section><section id="validator-vs-widget" class="informative"><h5>Validator vs. form widget</h5><p>A modern JSON Schema 2020-12 toolchain - ajv, the json-editor / jedison built-in validator, Hyperjump, Pydantic v2, OpenAPI 3.1 - honours <code>const</code> and keywords placed alongside <code>$ref</code>, so OO-LD's composition constructs validate as written; the older assumption that such tooling silently drops them does not hold for these validators. A narrower caveat concerns UI generation rather than validation: a form generator's <em>widget rendering</em> of a keyword may differ from what its <em>validator</em> enforces - for example json-editor validates <code>const</code> but does not necessarily render the field as a fixed value. A consumer restricted to a Draft-4-only JSON Schema processor remains the exception, since keywords adjacent to <code>$ref</code> and <code>const</code> are only guaranteed from later drafts.</p></section><section id="ui-delivery"><h5>Delivery: inline or overlay</h5><p>UI keywords may be embedded in the schema (inline):</p>
+<p><code>x-oold-ui-default-property</code> replaces the json-editor <code>defaultProperties</code> array (which listed the optional properties shown initially). That array is <em>extend-only</em> under composition: because composed schemas merge the arrays, a derived schema can add a default property but cannot switch one off. A per-property boolean is <em>overridable</em> - it resolves most-derived-wins (see <a href="#merge-and-override-model"></a>), so a derived schema sets it to <code>false</code> to hide a property a base schema showed. The same holds for a reverse property, which carries the boolean on its own definition.</p></section><section id="widget-hints"><h5>Widget hints: <code>format</code> vs <code>x-oold-ui-widget</code></h5><p><code>format</code> carries the widget hint when its value is a registered JSON Schema 2020-12 format (<code>date</code>, <code>date-time</code>, <code>time</code>, <code>duration</code>, <code>email</code>, <code>uri</code>, <code>iri</code>, <code>uuid</code>, ...); a validator may check it and a form generator picks the matching input. <span class="rule" id="OOLD-EXT-1e3c" tabindex="0" role="link" title="OOLD-EXT-1e3c - A widget hint that is not a registered format goes in x-oold-ui-widget, leaving format for validation.">A value that is not a registered format (<code>table</code>, <code>tabs</code>, <code>grid</code>, <code>autocomplete</code>, <code>textarea</code>, <code>checkbox</code>, <code>markdown</code>, <code>color</code>, ...) is widget-only and <em class="rfc2119">MUST</em> be carried in <code>x-oold-ui-widget</code> rather than <code>format</code>, which stays a validation assertion: a validator that checks declared formats would otherwise reject every value of the property.</span></p></section><section id="validator-vs-widget" class="informative"><h5>Validator vs. form widget</h5><p>A modern JSON Schema 2020-12 toolchain - ajv, the json-editor / jedison built-in validator, Hyperjump, Pydantic v2, OpenAPI 3.1 - honours <code>const</code> and keywords placed alongside <code>$ref</code>, so OO-LD's composition constructs validate as written; the older assumption that such tooling silently drops them does not hold for these validators. A narrower caveat concerns UI generation rather than validation: a form generator's <em>widget rendering</em> of a keyword may differ from what its <em>validator</em> enforces - for example json-editor validates <code>const</code> but does not necessarily render the field as a fixed value. A consumer restricted to a Draft-4-only JSON Schema processor remains the exception, since keywords adjacent to <code>$ref</code> and <code>const</code> are only guaranteed from later drafts.</p></section><section id="ui-delivery"><h5>Delivery: inline or overlay</h5><p>UI keywords may be embedded in the schema (inline):</p>
 <div class="ex-tabs">
 <div class="ex-tablist" role="tablist"><button class="ex-tab" role="tab" aria-selected="true" data-panel="ex10j">JSON</button><button class="ex-tab" role="tab" aria-selected="false" data-panel="ex10y">View as YAML</button></div>
 
@@ -1657,10 +1657,6 @@ <h2>Terminology</h2>
   <td><code>x-oold-reverse-required</code></td>
   <td>Names of reverse properties that are required.</td>
 </tr>
-<tr>
-  <td><code>x-oold-reverse-default-properties</code></td>
-  <td>Deprecated. Names of reverse properties shown by default in generated user interfaces. Like the object-level defaultProperties array this is extend-only under composition; prefer a per-reverse-property x-oold-ui-default-property boolean, which is overridable.</td>
-</tr>
 <tr>
   <td><code>@context</code></td>
   <td></td>