diff --git a/specification/archSpec/base/adding-an-attribute-to-certain-table-elements.dita b/specification/archSpec/base/adding-an-attribute-to-certain-table-elements.dita index 225e6b8c..4c955ca4 100644 --- a/specification/archSpec/base/adding-an-attribute-to-certain-table-elements.dita +++ b/specification/archSpec/base/adding-an-attribute-to-certain-table-elements.dita @@ -40,12 +40,6 @@

  1. Comments by Eliot Kimber:

    -

    [Re defining the attribute]: I don't really see the value in - having the "-expansion" distinction here--whether to use this - as a global attribute or through extension is really up to the - doc type shell author. The definer of the attribute domain may - intend for it to be used only on specific element types but - that's not really their choice to make."

    [Re the entity to be used in the @specializations attribute]: "Should there be leading and trailing space in the replacement text?"

    @@ -71,33 +65,21 @@ <!ATTLIST row %cellPurposeAtt-d-attribute-expansion;> <!ATTLIST colspec %cellPurposeAtt-d-attribute-expansion;> <!ATTLIST strow %cellPurposeAtt-d-attribute-expansion;> -<!ATTLIST stentry %cellPurposeAtt-d-attribute-expansion;>The - attribute definition entity ends in -expansion; - this indicates that this is an expansion attribute and should not - be included in the - base-attribute-extensions - entity in the document-type shell. -

    Comment by Eliot Kimber: "See my comment above: I don't - think we should do this."

    -     -

    Comment by Robert Anderson: "[The note] should clarify that - this entity is totally optional -- only useful here because - we're adding the same attribute with the same tokens to several - elements. If you're only adding one attribute to one element, - you wouldn't want this entity."

    -
    2. -
  2. The DITA architect updates the catalog.xml - file to include the expansion module. +<!ATTLIST stentry %cellPurposeAtt-d-attribute-expansion;>The attribute definition entity is optional. It is used + here to enable the DITA architect to add the same attribute with + the same tokens to several elements.
    3. +
  3. They then update the + catalog.xml file to include the expansion + module.

    Comment by Eliot Kimber: "This is something almost everybody *would* do but it's not actually required since the use of catalogs is not required by DITA or by the use of DTDs generally, at least in theory (and in actual fact if you are an Author/Editor user, which doesn't support catalogs)."

    4. -
  4. The DITA architect integrates this module into the applicable +
  5. They integrate this module into the applicable document-type shell.<!-- ============================================================= --> <!-- DOMAIN ATTRIBUTES DECLARATIONS --> @@ -109,8 +91,8 @@ PUBLIC "-//ACME//ENTITIES DITA Cell Purpose Attribute Expansion//EN" "cellPurposeAttExpansion.ent" >%cellPurposeAttExpansion-d-dec;
    6. -
  6. The DITA architect adds the entity for the contribution to the - specializations +
  7. They add the entity for the contribution to + the specializations attribute.<!-- ============================================================= --> <!-- SPECIALIZATIONS ATTRIBUTE OVERRIDE --> <!-- ============================================================= --> 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 6fb95c0d..a15d38b5 100644 --- a/specification/archSpec/base/example-contraints-redefine-content-model-attributes.dita +++ b/specification/archSpec/base/example-contraints-redefine-content-model-attributes.dita @@ -20,9 +20,8 @@
      -
    1. They create a .mod file - named idRequiredSectionContraint.mod, where - "idRequired" is a string that characterizes the constraint.
      2. +
    2. The DITA architect creates a constraint module: + idRequiredSectionContraint.mod.
    3. They add the following content to idRequiredSectionContraint.mod:<!-- Declares the entities referenced in the constrained content --> <!-- model. --> diff --git a/specification/archSpec/base/example-contraints-redefine-content-model.dita b/specification/archSpec/base/example-contraints-redefine-content-model.dita index e120444e..99c922b1 100644 --- a/specification/archSpec/base/example-contraints-redefine-content-model.dita +++ b/specification/archSpec/base/example-contraints-redefine-content-model.dita @@ -5,10 +5,10 @@ DTD 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 + document type. They want to omit the abstract element and make the shortdesc element required; the architect also wants to omit the + >they also want to omit the related-links element and disallow topic nesting. @@ -24,15 +24,9 @@
        -
      1. 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. The constraint module is named - acme-TopicConstraint.mod.
        2. -
      2. The architect adds the following content to +
      3. The DITA architect creates a constraint module: + acme-TopicConstraint.mod.
        4. +
      4. They add the following content to acme-TopicConstraint.mod: <!-- ============================================================= --> <!-- CONSTRAINED TOPIC ENTITIES --> @@ -54,11 +48,11 @@ (%prolog;)?, (%body;)?)" >
        5. -
      5. The architect adds the constraint module to - the catalog.xml file.
        6. -
      6. The architect then integrates the constraint - module into the document-type shell for topic by adding the - following section above the "TOPIC ELEMENT INTEGRATION" +
      7. They add the constraint module to the + catalog.xml file.
        8. +
      8. They then integrate 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 --> <!-- ============================================================= --> diff --git a/specification/archSpec/base/example-contraints-subset-domain.dita b/specification/archSpec/base/example-contraints-subset-domain.dita index 9d8166ee..38c8912d 100644 --- a/specification/archSpec/base/example-contraints-subset-domain.dita +++ b/specification/archSpec/base/example-contraints-subset-domain.dita @@ -24,10 +24,8 @@
          -
        1. They create - reducedHighlightingDomainConstraint.mod, - where "reduced" is a string that characterizes the - constraint.
          2. +
        2. TheDITA architect creates a constraint module: + reducedHighlightingDomainConstraint.mod.
        3. They add the following content to reducedHighlightingDomainConstraint.mod:<!-- ============================================================= --> <!-- CONSTRAINED HIGHLIGHT DOMAIN ENTITIES --> 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 ea9b468c..1ace1aee 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 @@ -21,20 +21,8 @@
            -
          1. 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.

            -
            2. +
          2. The DITA architect creates a constraint module: + id-requiredSectionContraintMod.rng.
          3. They update the catalog.xml file to include the new constraint module.
            4. 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 4ddbd87c..43816b17 100644 --- a/specification/archSpec/base/example-rng-constraints-redefine-content-model.dita +++ b/specification/archSpec/base/example-rng-constraints-redefine-content-model.dita @@ -24,12 +24,7 @@
              -
            1. 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 +
            2. The DITA architect creates a constraint module: acme-TopicConstraintMod.rng.
            3. They update the catalog.xml file to include the new @@ -51,12 +46,10 @@ </include> </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 +

              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 + start with copying-and-pasting from the module that they are overriding, they won't have that and will get errors.

            4. They then integrate the constraint module diff --git a/specification/archSpec/base/rng-adding-an-element-to-the-section-element.dita b/specification/archSpec/base/rng-adding-an-element-to-the-section-element.dita index 063a5c4c..328feb04 100644 --- a/specification/archSpec/base/rng-adding-an-element-to-the-section-element.dita +++ b/specification/archSpec/base/rng-adding-an-element-to-the-section-element.dita @@ -29,8 +29,10 @@ to the content model for section
                5. -
              1. First, the DITA architect creates the element domain module - (sectionDescDomain.rng):<?xml version="1.0" encoding="UTF-8"?> +
              2. First, the DITA architect creates the element domain + module: sectionDescDomain.rng. It contains + the following + code:<?xml version="1.0" encoding="UTF-8"?> <?xml-model href="urn:oasis:names:tc:dita:rng:vocabularyModuleDesc.rng" schematypens="http://relaxng.org/ns/structure/1.0"?> <grammar xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" diff --git a/specification/archSpec/base/rules-document-type-shells.dita b/specification/archSpec/base/rules-document-type-shells.dita index a083ae5d..9ff0ecdb 100644 --- a/specification/archSpec/base/rules-document-type-shells.dita +++ b/specification/archSpec/base/rules-document-type-shells.dita @@ -34,9 +34,10 @@ this rule are the following:
                • The ditabase document-type shell directly defines the dita element.
                  • -
                • RNG-based document-type shells directly specify values for the - specializations attribute; these values reflect the details of - the attribute domains that are integrated by the document-type shell.
                  • +
                • RNG-based document-type shells directly specify values + for the specializations attribute. These + values reflect the details of the attribute domains that + are integrated by the document-type shell.

                @@ -45,14 +46,17 @@

                Document-type shells that are not provided by OASIS MUST have a unique public identifier, if public identifiers are used.

                -

                Document-type shells that are not provided by OASIS MUST - NOT indicate OASIS as the owner; the public identifier or URN for such - document-type shells SHOULD reflect the owner or - creator of the document-type shell.

                -

                For example, if example.com creates a copy - of the document-type shell for topic, an appropriate public identifier would be - "-//EXAMPLE//DTD DITA Topic//EN", where "EXAMPLE" is the owner identifier component of - the public identifier. An appropriate URN would be +

                Document-type shells that are not provided by OASIS MUST NOT indicate OASIS as the + owner. The public identifier or URN for such document-type + shells SHOULD reflect the + owner or creator of the document-type shell.

                +

                For example, if + example.com creates a copy of the + document-type shell for topic, an appropriate public identifier + would be "-//EXAMPLE//DTD DITA Topic//EN", where "EXAMPLE" is + the component of the public identifier that identifies the + owner. An appropriate URN would be urn:example.com:names:dita:rng:topic.rng.

                diff --git a/specification/archSpec/base/specialization-including-non-dita-content.dita b/specification/archSpec/base/specialization-including-non-dita-content.dita index 95d6cc1f..d8f6dbdc 100644 --- a/specification/archSpec/base/specialization-including-non-dita-content.dita +++ b/specification/archSpec/base/specialization-including-non-dita-content.dita @@ -58,11 +58,10 @@ declaring the parameter entity before the reference to the svgDomain.ent file. Other foreign domains might need similar entities when required by the new vocabulary.

                - The following statement needs to be updated to refer to the - eventual final name of the DITA-techcomm package. -

                For more information, see the svgDomain.mod file that is shipped with - the OASIS DITA distributions. For an example of including the SVG domain in a document-type - shell, see task.dtd.

                +

                For more information, see the svgDomain.mod + file that is shipped with the DITA Technical Content + edition. For an example of including the SVG domain in a + document-type shell, see task.dtd.