A document-type shell integrates one or more topic type or map type modules, zero or more domain modules, and zero or more constraint modules.
Because RELAX NG modules are self-integrating, document-type shells only need to include vocabulary modules. Unlike DTDs, there is no separate specification required in order to integrate domain and nested topic elements into the base content models.
<start>
element defines one root element,
using a reference to a tagname.element pattern.
<div> <a:documentation>ROOT ELEMENT DECLARATION</a:documentation> <start combine="choice"> <ref name="topic.element"/> </start> </div>
@domains
attribute value. Unlike DTDs, a default
value for @domains
cannot automatically be constructed using RELAX NG
facilities. Instead, the values used to construct @domains
are taken
from each vocabulary and constraint module, in addition to any domains contributions
based on constraints implemented within the shell.
<div> <a:documentation>DOMAINS ATTRIBUTE</a:documentation> <define name="domains-att"> <optional> <attribute name="domains" a:defaultValue="(topic hazard-d) (topic hi-d) (topic indexing-d) (topic ut-d) a(props deliveryTarget)" /> </optional> </define> </div>
<div> <a:documentation>CONTENT CONSTRAINT INTEGRATION</a:documentation> <include href="strictTaskbodyConstraintMod.rng"> <define name="task-info-types"> <ref name="task.element"/> </define> </include> </div>
<div> <a:documentation>MODULE INCLUSIONS</a:documentation> <include href="topicMod.rng"/> <include href="highlightDomainMod.rng"/> <include href="utilitiesDomainMod.rng"/> <include href="indexingDomainMod.rng"/> <include href="hazardstatementDomainMod.rng"/> </div>
@domains
attribute; the
@domains
contribution should be documented in the document-type shell
with the constraint. There is not a designated section of the document-type shell for
this type of constraint; it can be placed either in Content constraint integration or Module inclusions.
The following example demonstrates the portion of a document type
shell that includes the highlight domain module while directly constraining that module
to remove the <u>
element. The
<ditaarch:domainsContribution>
element is used to document the
@domains
contribution for this constraint.
<div> <a:documentation>MODULE INCLUSIONS</a:documentation> <include href="topicMod.rng"/> <include href="hazardstatementDomainMod.rng"/> <include href="highlightDomainMod.rng"> <ditaarch:domainsContribution >(topic hi-d-noUnderline-c)</ditaarch:domainsContribution> <define name="u"> <notAllowed></notAllowed> </define> </include> <include href="indexingDomainMod.rng"/> <include href="utilitiesDomainMod.rng"/> </div>
@id
attribute with an XML data type of "ID". This declaration is
required in order to avoid errors from RELAX NG parsers that would otherwise complain
about different uses of the @id
attribute.
Typically, this section lists only a few elements, such as topic types or the
<anchor>
element, but it could include specializations that
constrain @id
. In addition, foreign vocabularies require you to include
exclusions for the namespaces used by those domains.
<topic>
and <task>
use an
@id
attribute with an XML data type of ID, along with any elements in
the SVG or MathML namespaces. Each of these is excluded from the "any" pattern by
placing them within the <except>
rule as shown
below:<div> <a:documentation> ID-DEFINING-ELEMENT OVERRIDES </a:documentation> <define name="any"> <zeroOrMore> <choice> <ref name="idElements"/> <element> <anyName> <except> <name>topic</name> <name>task</name> <nsName ns="http://www.w3.org/2000/svg"/> <nsName ns="http://www.w3.org/1998/Math/MathML"/> </except> </anyName> <zeroOrMore> <attribute> <anyName/> </attribute> </zeroOrMore> <ref name="any"/> </element> <text/> </choice> </zeroOrMore> </define> </div>
Return to main page.
dita-v1.3-errata01-os-part1-base-complete Standards Track Work Product | Copyright © OASIS Open 2016. All Rights Reserved. | 25 October 2016 |