Can rejectElements specifications be interpreted as true schema disallowance?
Posted: Fri Jan 21, 2022 8:30 pm
For content structure and formatting reasons, we specialize <ol> into <procedure> (and <li> into <step>):
Then, in cc_config_ext.xml, we try to disallow list-item elements in procedure elements and vice versa:
However, the rejectElements specification only seems to affect element insertion; it is not treated as a true schema disallowance. For example, if I attempt to insert a <step> into an <ol>, the insertion itself refuses the context, but then the search for the next-nearest-valid context creates another <ol> and puts it there:
Note that there is no red violation highlighting for <step> in <ol>. It seems inconsistent to me to disallow element insertion in some ways (element insertion), but allow it in others (next-nearest-valid context search, and existing elements once inserted).
I'm sure Oxygen is operating as designed here, but could this consistency be improved by treating rejectElements specifications as true schema disallowances? Or are there technical reasons why this cannot be done, like being unable to modify the internal schema representation in memory?
Here is a testcase, although it requires a DITA-OT plugin (included) to be installed:
Thanks!
Code: Select all
<elementdomain filename="snpsDomain.rng" domain="snps-d">
<specialize elements="procedure" from="ol"/>
<specialize elements="step" from="li"/>
</elementdomain>
Code: Select all
<!-- configure some content model restrictions -->
<elementProposals path="ol" rejectElements="step"/>
<elementProposals path="ul" rejectElements="step"/>
<elementProposals path="procedure" rejectElements="li"/>
Note that there is no red violation highlighting for <step> in <ol>. It seems inconsistent to me to disallow element insertion in some ways (element insertion), but allow it in others (next-nearest-valid context search, and existing elements once inserted).
I'm sure Oxygen is operating as designed here, but could this consistency be improved by treating rejectElements specifications as true schema disallowances? Or are there technical reasons why this cannot be done, like being unable to modify the internal schema representation in memory?
Here is a testcase, although it requires a DITA-OT plugin (included) to be installed:
Thanks!