Merge pull request #916 from robander/idatt

Modify working in ID attribute topic

specification/archSpec/base/id.dita

@@ -20,13 +20,12 @@
       of those <xmlatt>id</xmlatt> attributes be unique. However, the DITA specification requires
       that all IDs be unique within the context of a topic. For this reason, tools might provide an
       additional layer of validation to flag violations of this rule.</p>
-    <p>Within documents that contain multiple topics, the values of the <xmlatt>id</xmlatt>
-      attribute for all non-topic elements that have the same nearest-ancestor-topic element need to
-      be unique with respect to each other. The values of the <xmlatt>id</xmlatt> attribute for
-      non-topic elements can be the same as non-topic elements with different nearest-ancestor-topic
-      elements. Therefore, within a single DITA document that contains more than one topic, the
-      values of the <xmlatt>id</xmlatt> attribute of the non-topic elements need only to be unique
-      within each topic.</p>
+    <p>Within documents that contain multiple topics, identifiers are scoped to the individual
+      topic, excluding child topics. The values of the <xmlatt>id</xmlatt> attribute for all
+      non-topic elements only need to be unique within that topic. For example, within one document
+      a section can have the same <xmlatt>id</xmlatt> as another section as long as the two are in
+      different topics. This is true even if one of those topics is nested within the other; the
+      scope is determined by the closest topic element within the document hierarchy.</p>
     <p>Within a map document, the values of the <xmlatt>id</xmlatt> attributes for all elements
         <term outputclass="RFC-2119">SHOULD</term> be unique. When two elements
       within a map have the same value for the <xmlatt>id</xmlatt> attribute, processors <term
@@ -72,19 +71,10 @@
         </strow>
       </simpletable>
     </fig>
-    <draft-comment author="robander" audience="spec-editors" time="22 feb 2022">Changed "has no
-      impact on processing" to "has no required impact on processing". This is non-normative note so
-      language does not need to be quite so rigorous but what we're saying is that "adding or
-      removing an ID does not change how the specification requires that you process something" …
-      I'd be free to set up my *own* processing so that having an ID has an impact on
-        processing.<p>Secondary thought though, we say "For all elements", but that's not 100% true;
-        not having an ID on topic, where it's required, will result in parser errors and thus have
-        an impact on processing. We could simply change this to "For most elements" while retaining
-        the fn example.</p></draft-comment>
-    <note>For all elements other than footnote (<xmlelement>fn</xmlelement>), the presence of a
-      value for the <xmlatt>id</xmlatt> attribute has no impact on processing. For
-        <xmlelement>fn</xmlelement>, the presence or absence of a valid <xmlatt>id</xmlatt>
-      attribute affects how the element is processed. This is important for tools that automatically
-      assign <xmlatt>id</xmlatt> attributes to all elements.</note>
+    <note>For tools that automatically assign <xmlatt>id</xmlatt> attributes to elements, it is
+      important to recognize that the presence or absence of an <xmlatt>id</xmlatt> attribute on the
+        <xmlelement>fn</xmlelement> element will affect how the element is processed. For most other
+      elements, the presence of a value for the <xmlatt>id</xmlatt> attribute has no impact on
+      processing.</note>
   </conbody>
 </concept>