From e48a7f188f6331e75a748f1704a6929455661356 Mon Sep 17 00:00:00 2001
From: Kristen James Eberlein
Date: Wed, 13 Jul 2022 20:05:50 -0400
Subject: [PATCH] Updates for proposal 15
---
...nstraints-processing-interoperability.dita | 10 ---
.../archSpec/base/ditaspecialization.dita | 4 +-
.../example-constrain-a-domain-using-rng.dita | 35 ++++++-----
...nts-redefine-content-model-attributes.dita | 56 ++++++++++-------
...ple-contraints-redefine-content-model.dita | 40 +++++++-----
...lace-base-element-w-domain-extensions.dita | 22 ++++---
.../example-contraints-subset-domain.dita | 42 ++++++++-----
...onstraints-apply-multiple-constraints.dita | 25 ++++----
...nts-redefine-content-model-attributes.dita | 63 +++++++++++--------
...ng-constraints-redefine-content-model.dita | 61 ++++++++++--------
...lace-base-element-w-domain-extensions.dita | 18 +++---
...ting-constraint-and-expansion-modules.dita | 5 +-
.../base/specialization-class-attribute.dita | 17 +----
specification/resources/DITA2.0-spec.ditaval | 5 +-
14 files changed, 221 insertions(+), 182 deletions(-)
diff --git a/specification/archSpec/base/constraints-processing-interoperability.dita b/specification/archSpec/base/constraints-processing-interoperability.dita
index 45aa73ce..ae85385d 100644
--- a/specification/archSpec/base/constraints-processing-interoperability.dita
+++ b/specification/archSpec/base/constraints-processing-interoperability.dita
@@ -31,15 +31,5 @@
a shortdesc element. However, if the task document type also has been
constrained to require the shortdesc element, it is compatible with the
constrained topic document type.
-
- For DITA 2.0, we've removed the requirement to add tokens for constraints; accordingly I
- removed the following paragraph:
- "A constrained document type allows only a subset of the possible instances of the
- unconstrained document type. Thus, for a processor to determine whether a document instance is
- compatible with another document type, the document instance MUST declare any constraints on the document type."
- Does this topic make sense without that paragraph? How do we need to rework it? Does it need
- to cover anything about
-
diff --git a/specification/archSpec/base/ditaspecialization.dita b/specification/archSpec/base/ditaspecialization.dita
index 7e121e1c..b40f5570 100644
--- a/specification/archSpec/base/ditaspecialization.dita
+++ b/specification/archSpec/base/ditaspecialization.dita
@@ -45,8 +45,8 @@
- Constraint
- - Constraint modules enables the restriction of content models and attribute lists
- for individual elements.
+ - Constraint modules enable the restriction of content
+ models and attribute lists for individual elements.
- Expansion
diff --git a/specification/archSpec/base/example-constrain-a-domain-using-rng.dita b/specification/archSpec/base/example-constrain-a-domain-using-rng.dita
index b60fc0de..df971bbe 100644
--- a/specification/archSpec/base/example-constrain-a-domain-using-rng.dita
+++ b/specification/archSpec/base/example-constrain-a-domain-using-rng.dita
@@ -2,12 +2,15 @@
Example: Constrain a domain module using RNG
- In this scenario, an information architect wants to use only a subset of the elements
- defined in the highlighting domain. She wants to use b and
- i but not line-through,
- overline, sup,
- sup, tt, or
- u. Her implementation uses RNG for its grammar files.
+ In this scenario, a DITA architect wants
+ to use only a subset of the elements defined in the highlighting
+ domain. They want to use b
+ and i but not
+ line-through,
+ overline, sup,
+ sup, tt, or
+ u. Their implementation
+ uses RNG for its grammar files.
@@ -22,9 +25,10 @@
When using RNG, domains can be constrained directly in the document-type shells.
-
-
She opens the document-type shell for topic in an XML editor, and then modifies the
- "MODULE INCLUSIONS" division to exclude the elements that she does not want the
- implementation to use:
+ They open the document-type shell for topic
+ in an XML editor, and then they modify the
+ "MODULE INCLUSIONS" division to exclude the elements that they do not want the implementation to use:
<div>
<a:documentation>MODULE INCLUSIONS</a:documentation>
...
@@ -50,12 +54,15 @@
</include>
..
</div>
- The information architect made a choice as to where in the document-type shell she
- would implement the constraint. It can be placed either in the "Element-type configuration
- integration" or the "Module inclusions" section.
+ The DITA architect made a choice as to
+ where in the document-type shell they would
+ implement the constraint. It can be placed either in the
+ "Element-type configuration integration" or the "Module
+ inclusions" section.
- - She makes similar changes to all the other document-type shells in which she wants
- to constrain the highlighting domain.
+ - They make similar changes to all the
+ other document-type shells in which they want to
+ constrain the highlighting domain.
diff --git a/specification/archSpec/base/example-contraints-redefine-content-model-attributes.dita b/specification/archSpec/base/example-contraints-redefine-content-model-attributes.dita
index ea3219a9..6fb95c0d 100644
--- a/specification/archSpec/base/example-contraints-redefine-content-model-attributes.dita
+++ b/specification/archSpec/base/example-contraints-redefine-content-model-attributes.dita
@@ -3,9 +3,10 @@
Example: Constrain attributes for the section element using
DTD
- In this scenario, an information architect wants to redefine the attributes for the
- section element. He wants to make the id attribute
- required.
+ In this scenario, a DITA architect wants to
+ redefine the attributes for the section
+ element. They want to make the id
+ attribute required.
@@ -19,10 +20,10 @@
- - He creates a .mod file named
- idRequiredSectionContraint.mod, where "idRequired" is a string that
- characterizes the constraint.
- - He adds the following content to
+
- They create a .mod file
+ named idRequiredSectionContraint.mod, where
+ "idRequired" is a string that characterizes the constraint.
+ - They add the following content to
idRequiredSectionContraint.mod:<!-- Declares the entities referenced in the constrained content -->
<!-- model. -->
@@ -109,22 +110,31 @@
outputclass
CDATA
#IMPLIED"
->The information architect had to declare all the parameter entities
- that are referenced in the redefined attributes for section. If
- he did not do so, none of the attributes that are declared in the parameter entities
- would be available on the section element. Furthermore, since
- the select-atts parameter entity references the
- filter-atts parameter entity, the
- filter-atts must be declared and it must precede
- the declaration for the select-atts parameter entity.
- The props-attribute-extensions and
- base-attribute-extensions parameter entities do not
- need to be declared in the constraint module, because they are declared in the
- document-type shells before the inclusion of the constraint module.
- - He adds the constraint module to the catalog.xml file.
- - He then integrates the constraint module into the applicable document-type shells.
- - After checking test topics to ensure that the content model is modified as expected, his
- work is done.
+>The DITA architect had to declare all the
+ parameter entities that are referenced in the redefined
+ attributes for section. If they did not do so, none of the attributes
+ that are declared in the parameter entities would be available
+ on the section element. Furthermore,
+ since the select-atts
+ parameter entity references the
+ filter-atts parameter
+ entity, the filter-atts must
+ be declared and it must precede the declaration for the
+ select-atts parameter
+ entity. The
+ props-attribute-extensions
+ and
+ base-attribute-extensions
+ parameter entities do not need to be declared in the constraint
+ module, because they are declared in the document-type shells
+ before the inclusion of the constraint module.
+ - They add the constraint module to the
+ catalog.xml file.
+ - They then integrate the constraint module
+ into the applicable document-type shells.
+ - After checking the test topics to ensure that the content model
+ is modified as expected, the work is done.
diff --git a/specification/archSpec/base/example-contraints-redefine-content-model.dita b/specification/archSpec/base/example-contraints-redefine-content-model.dita
index 2e756680..e120444e 100644
--- a/specification/archSpec/base/example-contraints-redefine-content-model.dita
+++ b/specification/archSpec/base/example-contraints-redefine-content-model.dita
@@ -3,11 +3,14 @@
Example: Redefine the content model for the topic element using
DTD
- In this scenario, an information architect for Acme, Incorporated wants to redefine the
- content model for the topic document type. She wants to omit the
- abstract element and make the shortdesc
- element required; she also wants to omit the related-links element and
- disallow topic nesting.
+ In this scenario, the DITA architect for
+ Acme, Incorporated wants to redefine the content model for the topic
+ document type. The architect wants to omit the
+ abstract element and make the
+ shortdesc element required; the architect also wants to omit the
+ related-links element and disallow topic
+ nesting.
@@ -21,13 +24,16 @@
- - She creates a .mod file using the following naming conventions:
+
- The architect creates a
+ .mod file using the following naming
+ conventions:
qualiferTagnameConstraint.mod,
- where qualifer is a string the describes the constraint, and
- Tagname is the element type name with an initial capital. Her
- constraint module is named acme-TopicConstraint.mod.
- - She adds the following content to
- acme-TopicConstraint.mod:
+ where qualifer is a string the describes the
+ constraint, and Tagname is the element type
+ name with an initial capital. The constraint module is named
+ acme-TopicConstraint.mod.
+ - The architect adds the following content to
+ acme-TopicConstraint.mod:
<!-- ============================================================= -->
<!-- CONSTRAINED TOPIC ENTITIES -->
<!-- ============================================================= -->
@@ -48,9 +54,11 @@
(%prolog;)?,
(%body;)?)"
>
- - She adds the constraint module to the catalog.xml file.
- - She then integrates the constraint module into her document-type shell for topic by
- adding the following section above the "TOPIC ELEMENT INTEGRATION"
+
- The architect adds the constraint module to
+ the catalog.xml file.
+ - The architect then integrates the constraint
+ module into the document-type shell for topic by adding the
+ following section above the "TOPIC ELEMENT INTEGRATION"
comment:<!-- ============================================================= -->
<!-- ELEMENT-TYPE CONFIGURATION INTEGRATION -->
<!-- ============================================================= -->
@@ -59,8 +67,8 @@
PUBLIC "-//ACME//ELEMENTS DITA Topic Constraint//EN"
"acme-TopicConstraint.mod">
%topic-constraints-c-def;
- - After checking her test topic to ensure that the content model is modified as expected,
- her work is done.
+ - After checking the test topic to ensure that the content model
+ is modified as expected, the work is done.
diff --git a/specification/archSpec/base/example-contraints-replace-base-element-w-domain-extensions.dita b/specification/archSpec/base/example-contraints-replace-base-element-w-domain-extensions.dita
index 1d3389c4..ba5e5be0 100644
--- a/specification/archSpec/base/example-contraints-replace-base-element-w-domain-extensions.dita
+++ b/specification/archSpec/base/example-contraints-replace-base-element-w-domain-extensions.dita
@@ -2,9 +2,10 @@
Example: Replace a base element with the domain extensions using DTD
- In this scenario, an information architect wants to remove the
- ph element but allow the extensions of ph
- that exist in the highlighting, programming, software, and user interface domains.
+ In this scenario, a DITA architect wants to
+ remove the ph element but allow the extensions
+ of ph that exist in the highlighting,
+ programming, software, and user interface domains.
@@ -18,18 +19,21 @@
- - In the "DOMAIN EXTENSIONS" section, the information architect removes the reference to
- the ph
+
- In the "DOMAIN EXTENSIONS" section, the DITA
+ architect removes the reference to the
+ ph
element:<!-- Removed "ph | " so as to make <ph> not available, only the domain extensions. -->
<!ENTITY % ph "%pr-d-ph; |
%sw-d-ph; |
%ui-d-ph;
">
- Because no other entities are modified or declared outside of the usual "DOMAIN
- EXTENSIONS" section, this completes the information architect's task. Because no new grammar
- file or entity is created that would highlight this change, adding a comment to highlight
- the constraint becomes particularly important (as shown in the example above).
+ Because no other entities are modified or declared outside of
+ the usual "DOMAIN EXTENSIONS" section, this completes the
+ architect's task. Because no new grammar file or entity is created
+ that would highlight this change, adding a comment to highlight the
+ constraint becomes particularly important (as shown in the example
+ above).
diff --git a/specification/archSpec/base/example-contraints-subset-domain.dita b/specification/archSpec/base/example-contraints-subset-domain.dita
index 7bcfec65..9d8166ee 100644
--- a/specification/archSpec/base/example-contraints-subset-domain.dita
+++ b/specification/archSpec/base/example-contraints-subset-domain.dita
@@ -2,12 +2,15 @@
Example: Constrain a domain module using DTD
- In this scenario, an information architect wants to use only a subset of the elements
- defined in the highlighting domain. She wants to use b and
- i, but not line-through,
- overline, sup, sup,
- tt, or u. She wants to integrate this
- constraint into the document-type shell for task.
+ In this scenario, a DITA architect wants to
+ use only a subset of the elements defined in the highlighting domain.
+ They want to use b and
+ i, but not
+ line-through,
+ overline, sup,
+ sup, tt, or
+ u. They want to integrate
+ this constraint into the document-type shell for task.
@@ -21,18 +24,22 @@
- - She creates reducedHighlightingDomainConstraint.mod, where
- "reduced" is a string that characterizes the constraint.
- - She adds the following content to
+
- They create
+ reducedHighlightingDomainConstraint.mod,
+ where "reduced" is a string that characterizes the
+ constraint.
+ - They add the following content to
reducedHighlightingDomainConstraint.mod:<!-- ============================================================= -->
<!-- CONSTRAINED HIGHLIGHT DOMAIN ENTITIES -->
<!-- ============================================================= -->
<!ENTITY % HighlightingDomain-c-ph "b | i" >
- - She adds the constraint module to the catalog.xml file.
- - She then integrates the constraint module into her company-specific, document-type shell
- for the task topic by adding the following section directly before the "DOMAIN ENTITY
- DECLARATIONS"
+
- They add the constraint module to the
+ catalog.xml file.
+ - They then integrate the constraint module
+ into the company-specific, document-type shell for the task topic
+ by adding the following section directly before the "DOMAIN
+ ENTITY DECLARATIONS"
comment:<!-- ============================================================= -->
<!-- DOMAIN CONSTRAINT INTEGRATION -->
<!-- ============================================================= -->
@@ -41,15 +48,16 @@
PUBLIC "-//ACME//ENTITIES DITA Highlighting Domain Constraint//EN"
"acme-HighlightDomainConstraint.mod"
>%HighlightDomain-c-dec;
- - In the "DOMAIN EXTENSIONS" section, she replaces the parameter entity for the
- highlighting domain with the parameter entity for the constrained highlighting
+
- In the "DOMAIN EXTENSIONS" section, they
+ replace the parameter entity for the highlighting domain
+ with the parameter entity for the constrained highlighting
domain:<!ENTITY % ph "ph |
%HighlightDomain-c-ph; |
%sw-d-ph; |
%ui-d-ph;
">
- - After checking her test topic to ensure that the content model is modified as expected,
- her work is done.
+ - After checking the test topic to ensure that the content model
+ is modified as expected, the work is done.
diff --git a/specification/archSpec/base/example-rng-constraints-apply-multiple-constraints.dita b/specification/archSpec/base/example-rng-constraints-apply-multiple-constraints.dita
index 8b9e8567..c8ce0b62 100644
--- a/specification/archSpec/base/example-rng-constraints-apply-multiple-constraints.dita
+++ b/specification/archSpec/base/example-rng-constraints-apply-multiple-constraints.dita
@@ -2,8 +2,8 @@
Example: Apply multiple constraints to a single document-type shell using RNG
- In this scenario, an information architect wants to apply multiple constraints to a
- document-type shell.
+ In this scenario, the DITA architect wants
+ to apply multiple constraints to a document-type shell.
@@ -59,8 +59,9 @@
directly in the document-type shell.
-
-
The information architect creates a constraint module that combines the constraints
- from example-TopicConstraint.mod and
+
The DITA architect creates a constraint
+ module that combines the constraints from
+ example-TopicConstraint.mod and
example-SectionConstraint.mod:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="urn:oasis:names:tc:dita:rng:vocabularyModuleDesc.rng"
@@ -98,16 +99,17 @@
</grammar>
-
-
In the document-type shell, the information architect integrates the constraint module
- (and removes the inclusion statement for topicMod.rng):
+ In the document-type shell, they integrate
+ the constraint module (and remove the
+ inclusion statement for topicMod.rng):
<div>
<a:documentation>ELEMENT-TYPE CONFIGURATION INTEGRATION</a:documentation>
<include href="acme-SectionTopicContraintMod.rng"/>
</div>
-
-
To constrain the highlight domain, the information architect modifies the include
- statement for the domain module:
+ To constrain the highlight domain, they
+ modify the include statement for the domain module:
<div>
<a:documentation>MODULE INCLUSIONS</a:documentation>
...
@@ -134,15 +136,12 @@
..
</div>
- - Finally, to disallow ph, the information architect adds the
- following statement to the constraint
+
- Finally, to disallow ph, they add the following statement to the constraint
module: <define name="ph.element">
<notAllowed/>
</define>
-
diff --git a/specification/archSpec/base/example-rng-constraints-redefine-content-model-attributes.dita b/specification/archSpec/base/example-rng-constraints-redefine-content-model-attributes.dita
index 1aced16f..ea9b468c 100644
--- a/specification/archSpec/base/example-rng-constraints-redefine-content-model-attributes.dita
+++ b/specification/archSpec/base/example-rng-constraints-redefine-content-model-attributes.dita
@@ -4,9 +4,10 @@
id="reference_cfb_ck4_5pexample-rng-constraints-redefine-content-model-attributes">
Example: Constrain attributes for the section element using
RNG
- In this scenario, an information architect wants to redefine the attributes for the
- section element. He wants to make the id attribute
- required.
+ In this scenario, a DITA architect wants to
+ redefine the attributes for the section
+ element. They want to make the id
+ attribute required.
@@ -20,19 +21,25 @@
- - He creates a file named id-requiredSectionContraintMod.rng, where
- id-required is a string that characterizes the
- constraint.
-
Comment from Robert Anderson: "Section 8.5.5.2, seems odd to me that we say "...where
- id-required is a string that characterizes the constraint." First, because that's
- clear from what we're doing, and second, because the author could use any name they
- want."
- Reminder to check other example topics (constraint and expansion) to see how often we
- provide info about conventions for file naming, and then talk to Robert about it.
+ - They create a file named
+ id-requiredSectionContraintMod.rng, where
+ id-required is a string that characterizes
+ the constraint.
+
Comment from Robert Anderson: "Section 8.5.5.2, seems odd to
+ me that we say "...where id-required is a string that
+ characterizes the constraint." First, because that's clear
+ from what we're doing, and second, because the author could
+ use any name they want."
+ Reminder to check other example topics (constraint and
+ expansion) to see how often we provide info about conventions
+ for file naming, and then talk to Robert about it.
- - He updates the catalog.xml file to include the new constraint
- module.
- - He adds the following content to the constraint
+
- They update the
+ catalog.xml file to include the new
+ constraint module.
+ - They add the following content to the
+ constraint
module:<?xml version="1.0" encoding="UTF-8"?>
<grammar
xmlns="http://relaxng.org/ns/structure/1.0"
@@ -57,19 +64,23 @@
</include>
</div>
-</grammar>
Note that unlike a constraint module that is implemented
- using DTD, this constraint module did not need to re-declare the patterns that are
- referenced in the redefinition of the content model for
- section
- - He then integrates the constraint module into her document-type shell for topic by
- adding an include element in the "CONTENT CONSTRAINT INTEGRATION"
- section:<div>
+</grammar>
Note that unlike a constraint
+ module that is implemented using DTD, this constraint module
+ did not need to re-declare the patterns that are referenced in
+ the redefinition of the content model for
+ section
+ - They then integrate the constraint module
+ into the document-type shell for topic by adding an
+ include element in the "CONTENT
+ CONSTRAINT INTEGRATION" section:<div>
<a:documentation>CONTENT CONSTRAINT INTEGRATION</a:documentation>
<include href="id-requiredSectionConstraintMod.rng"/>
</div>
-
-
He then removes the include statement that references
- topicMod.rng from the "MODULE INCLUSIONS" section:
+ They then remove the
+ include statement that references
+ topicMod.rng from the "MODULE
+ INCLUSIONS" section:
<div>
<a:documentation>MODULE INCLUSIONS </a:documentation>
<include href="urn:oasis:names:tc:dita:rng:topicMod.rng:2.0"/>
@@ -81,8 +92,8 @@
<include href="urn:oasis:names:tc:dita:rng:highlightDomain.rng:2.0"/>
</div>
- - After checking his test topic to ensure that the attribute list is modified as expected,
- his work is done.
+ - After checking the test topic to ensure that the attribute list
+ is modified as expected, the work is done.
diff --git a/specification/archSpec/base/example-rng-constraints-redefine-content-model.dita b/specification/archSpec/base/example-rng-constraints-redefine-content-model.dita
index 207f63e9..4ddbd87c 100644
--- a/specification/archSpec/base/example-rng-constraints-redefine-content-model.dita
+++ b/specification/archSpec/base/example-rng-constraints-redefine-content-model.dita
@@ -3,11 +3,14 @@
Example: Redefine the content model for the topic element using
RNG
- In this scenario, an information architect for Acme, Incorporated wants to redefine the
- content model for the topic document type. She wants to omit the
- abstract element and make the shortdesc
- element required; she also wants to omit the related-links element and
- disallow topic nesting.
+ In this scenario, a DITA architect for
+ Acme, Incorporated wants to redefine the content model for the topic
+ document type. They want to omit the
+ abstract element and make the
+ shortdesc element required; they also want to omit the
+ related-links element and disallow topic
+ nesting.
@@ -21,14 +24,17 @@
- - She creates a .mod file using the following naming conventions:
+
- They create a .mod file
+ using the following naming conventions:
qualiferTagnameConstraintMod.rng,
- where qualifer is a string the describes the constraint, and
- Tagname is the element type name with an initial capital. Her
- constraint module is named acme-TopicConstraintMod.rng.
- - She updates the catalog.xml file to include the new constraint
- module.
- - She adds the following content to
+ where qualifer is a string the describes the
+ constraint, and Tagname is the element type
+ name with an initial capital. Her constraint module is named
+ acme-TopicConstraintMod.rng.
+ - They update the
+ catalog.xml file to include the new
+ constraint module.
+ - They add the following content to
acme-TopicConstraint.mod:<div>
<a:documentation>CONTENT MODEL OVERRIDES</a:documentation>
<include href="urn:oasis:names:tc:dita:rng:topicMod.rng:2.0">
@@ -43,23 +49,28 @@
</optional>
</define>
</include>
-</div>
-
We need to change the header to "ATTRIBUTE AND CONTENT MODEL OVERRIDES" in the
- constraint module that we ship.
+</div>
+ We need to change the header to "ATTRIBUTE AND CONTENT MODEL
+ OVERRIDES" in the constraint module that we ship.
Also, I know that the override won't happen without
- combine="interleave", but I don't know if we cover that in the
- coding requirements topic. If people start with copy-ing-and-pasting from the module
- that they are overriding, they won't have that and will get errors.
+ combine="interleave", but I don't know if
+ we cover that in the coding requirements topic. If people
+ start with copy-ing-and-pasting from the module that they are
+ overriding, they won't have that and will get errors.
- - She then integrates the constraint module into her document-type shell for topic by
- adding an include element in the "ELEMENT-TYPE CONFIGURATION
- INTEGRATION" section:<div>
+
- They then integrate the constraint module
+ into the document-type shell for topic by adding an
+ include element in the "ELEMENT-TYPE
+ CONFIGURATION INTEGRATION" section:<div>
<a:documentation>ELEMENT-TYPE CONFIGURATION INTEGRATION</a:documentation>
<include href="acme-TopicConstraintMod.rng"/>
</div>
-
-
She then removes the include statement that references
- topicMod.rng from the "MODULE INCLUSIONS" section:
+ They then remove the
+ include statement that references
+ topicMod.rng from the "MODULE
+ INCLUSIONS" section:
<div>
<a:documentation>MODULE INCLUSIONS </a:documentation>
<include href="urn:oasis:names:tc:dita:rng:topicMod.rng:2.0"/>
@@ -71,8 +82,8 @@
<include href="urn:oasis:names:tc:dita:rng:highlightDomain.rng:2.0"/>
</div>
- - After checking her test topic to ensure that the content model is modified as expected,
- her work is done.
+ - After checking the test topic to ensure that the content model
+ is modified as expected, the work is done.
diff --git a/specification/archSpec/base/example-rng-constraints-replace-base-element-w-domain-extensions.dita b/specification/archSpec/base/example-rng-constraints-replace-base-element-w-domain-extensions.dita
index 4aead178..b8525624 100644
--- a/specification/archSpec/base/example-rng-constraints-replace-base-element-w-domain-extensions.dita
+++ b/specification/archSpec/base/example-rng-constraints-replace-base-element-w-domain-extensions.dita
@@ -2,9 +2,10 @@
Example: Replace a base element with the domain extensions using RNG
- In this scenario, an information architect wants to remove the
- ph element but allow the extensions of ph
- that exist in the highlight, programming, software, and user interface domains.
+ In this scenario, the DITA architect wants
+ to remove the ph element but allow the
+ extensions of ph that exist in the highlight,
+ programming, software, and user interface domains.
@@ -19,8 +20,10 @@
-
-
She opens the document-type shell for topic in an XML editor, and then modifies the
- "MODULE INCLUSIONS" division to exclude ph:
+ They open the document-type shell for topic
+ in an XML editor, and then they modify the
+ "MODULE INCLUSIONS" division to exclude
+ ph:
<div>
<a:documentation>MODULE INCLUSIONS</a:documentation>
<include href="urn:oasis:names:tc:dita:rng:topicMod.rng:2.0">
@@ -31,8 +34,9 @@
...
</div>
- - She makes similar changes to all the other document-type shells in which she wants
- ph to not be available
+ - They make similar changes to all the other
+ document-type shells in which they want
+ ph to not be available
diff --git a/specification/archSpec/base/rng-aggregating-constraint-and-expansion-modules.dita b/specification/archSpec/base/rng-aggregating-constraint-and-expansion-modules.dita
index 5939367a..908953e0 100644
--- a/specification/archSpec/base/rng-aggregating-constraint-and-expansion-modules.dita
+++ b/specification/archSpec/base/rng-aggregating-constraint-and-expansion-modules.dita
@@ -122,8 +122,9 @@
</div>
</grammar>
- When the DITA architect edits the document-type shell to integrate the element
- configuration module, she also needs to do the following:
+ When the DITA architect edits the document-type shell to
+ integrate the element configuration module, they also
+ need to do the following:
- Remove the include statement for topicMod.rng
- Add section to the "ID-DEFINING ELEMENT OVERRIDES"
diff --git a/specification/archSpec/base/specialization-class-attribute.dita b/specification/archSpec/base/specialization-class-attribute.dita
index 3bc2883c..64370085 100644
--- a/specification/archSpec/base/specialization-class-attribute.dita
+++ b/specification/archSpec/base/specialization-class-attribute.dita
@@ -50,22 +50,7 @@
Rules
- Question about the following statement. If a topic has no
- integrated attribute domains in 2.0, the value of @specializations will be empty. Is this
- really a MUST? Should we clarify to indicate that this must be declared in the grammar, but
- does not necessarily need to have a value - I know that has caused confusion in the past for
- a tool that reported errors for empty @domains
Response by Eliot Kimber, 18 May 2021:
- If @specializations is only relevant to attribute specializations then I think it would
- be sensible to allow it to be omitted, with an omitted @specializations being equivalent
- to specializations="" (empty or whitespace-only value).
- The counter to that approach is that you can't easily distinguish between really having
- no attribute specializations and just forgetting to provide @specializations, but in
- that case I think you'd get runtime failures if you actually had specializations that
- weren't declared (i.e., your @props specializations aren't recognized so things don't
- filter correctly).
- Seems like an edge case in practice since DITA defines a number of out-of-the box
- attribute specializations, including now all of the original conditional attributes.
-
+
Every DITA element (except the dita element that is used as the
root of a ditabase document) MUST declare a
class attribute.
diff --git a/specification/resources/DITA2.0-spec.ditaval b/specification/resources/DITA2.0-spec.ditaval
index 7d04d0b8..08e511b8 100644
--- a/specification/resources/DITA2.0-spec.ditaval
+++ b/specification/resources/DITA2.0-spec.ditaval
@@ -122,12 +122,13 @@
◄
-->
-
+
+
-
+