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.

  1. -

    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.
    2. -
  2. She makes similar changes to all the other document-type shells in which she wants - to constrain the highlighting domain.
    3. +
  3. 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 <xmlelement>section</xmlelement> 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 @@
    -
  1. He creates a .mod file named - idRequiredSectionContraint.mod, where "idRequired" is a string that - characterizes the constraint.
    2. -
  2. He adds the following content to +
  3. They create a .mod file + named idRequiredSectionContraint.mod, where + "idRequired" is a string that characterizes the constraint.
    4. +
  4. 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.
    5. -
  5. He adds the constraint module to the catalog.xml file.
    6. -
  6. He then integrates the constraint module into the applicable document-type shells.
    7. -
  7. After checking test topics to ensure that the content model is modified as expected, his - work is done.
    8. +>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. +
  8. They add the constraint module to the + catalog.xml file.
    9. +
  9. They then integrate the constraint module + into the applicable document-type shells.
    10. +
  10. 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 <xmlelement>topic</xmlelement> 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 @@
    -
  1. She creates a .mod file using the following naming conventions: +
  2. 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.
    3. -
  3. 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.
    4. +
  4. The architect adds the following content to + acme-TopicConstraint.mod: <!-- ============================================================= --> <!-- CONSTRAINED TOPIC ENTITIES --> <!-- ============================================================= --> @@ -48,9 +54,11 @@ (%prolog;)?, (%body;)?)" >
    5. -
  5. She adds the constraint module to the catalog.xml file.
    6. -
  6. She then integrates the constraint module into her document-type shell for topic by - adding the following section above the "TOPIC ELEMENT INTEGRATION" +
  7. The architect adds the constraint module to + the catalog.xml file.
    8. +
  8. 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;
    9. -
  9. After checking her test topic to ensure that the content model is modified as expected, - her work is done.
    10. +
  10. 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 @@
    -
  1. In the "DOMAIN EXTENSIONS" section, the information architect removes the reference to - the ph +
  2. 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 @@
    -
  1. She creates reducedHighlightingDomainConstraint.mod, where - "reduced" is a string that characterizes the constraint.
    2. -
  2. She adds the following content to +
  3. They create + reducedHighlightingDomainConstraint.mod, + where "reduced" is a string that characterizes the + constraint.
    4. +
  4. They add the following content to reducedHighlightingDomainConstraint.mod:<!-- ============================================================= --> <!-- CONSTRAINED HIGHLIGHT DOMAIN ENTITIES --> <!-- ============================================================= --> <!ENTITY % HighlightingDomain-c-ph "b | i" >
    5. -
  5. She adds the constraint module to the catalog.xml file.
    6. -
  6. 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" +
  7. They add the constraint module to the + catalog.xml file.
    8. +
  8. 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;
    9. -
  9. In the "DOMAIN EXTENSIONS" section, she replaces the parameter entity for the - highlighting domain with the parameter entity for the constrained highlighting +
  10. 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; ">
    11. -
  11. After checking her test topic to ensure that the content model is modified as expected, - her work is done.
    12. +
  12. 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.

  1. -

    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>
  2. -

    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>
  3. -

    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>
    4. -
  4. Finally, to disallow ph, the information architect adds the - following statement to the constraint +
  5. 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 <xmlelement>section</xmlelement> 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 @@
    -
  1. 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.

    +
  2. 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.

    3. -
  3. He updates the catalog.xml file to include the new constraint - module.
    4. -
  4. He adds the following content to the constraint +
  5. They update the + catalog.xml file to include the new + constraint module.
    6. +
  6. 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

    7. -
  7. 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

    8. +
  8. 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>
  9. -

    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>
    10. -
  10. After checking his test topic to ensure that the attribute list is modified as expected, - his work is done.
    11. +
  11. 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 <xmlelement>topic</xmlelement> 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 @@
    -
  1. She creates a .mod file using the following naming conventions: +
  2. 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.
    3. -
  3. She updates the catalog.xml file to include the new constraint - module.
    4. -
  4. 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.
    5. +
  5. They update the + catalog.xml file to include the new + constraint module.
    6. +
  6. 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.

    7. -
  7. 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> +
  8. 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>
  9. -

    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>
    10. -
  10. After checking her test topic to ensure that the content model is modified as expected, - her work is done.
    11. +
  11. 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 @@
  1. -

    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>
    2. -
  2. She makes similar changes to all the other document-type shells in which she wants - ph to not be available
    3. +
  3. 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 @@ ◄ --> - + + - +