From 785e2e73aff2ac87dba2029e4d413957bfd7e209 Mon Sep 17 00:00:00 2001 From: Webb Roberts Date: Wed, 14 Oct 2020 17:42:08 -0400 Subject: [PATCH] Fixed error "used to by" in section 10.4. Closes https://github.com/NIEM/NIEM-NDR/issues/95. --- publish/niem-ndr.html | 2 +- publish/niem-ndr.txt | 2 +- src/ndr-doc.xml.m4 | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/publish/niem-ndr.html b/publish/niem-ndr.html index 2ee02ce..f07a40a 100644 --- a/publish/niem-ndr.html +++ b/publish/niem-ndr.html @@ -798,7 +798,7 @@ = exists(@name[ends-with(., 'Association')])" >An element MUST have a name that ends in 'Association' if and only if it has a type that is an association type.</sch:assert> </sch:rule> -</sch:pattern>

Using the qualifier Association immediately identifies an element as representing an association. This document defines the term association type.

10.4. Augmentations

Developers of domain schemas and other schemas that build on and extend the NIEM release schemas need to be able to define additional characteristics of common types. For example, the JXDM domain, which addresses justice and public safety concerns, considers the following elements to be characteristics of a person, as defined by nc:PersonType:

There are several approaches that could be used to by a domain to add elements to a common type. One method is to have each domain create an extension of nc:PersonType (using xs:extension) that adds elements and attributes for the needed content. Some of the problems with this approach include:

This approach turns into a morass that is difficult to use and maintain, and which does not scale to support the breadth of the NIEM community.

To handle this need, NIEM has adopted augmentations. There are several parts that fit together for the definition and use of augmentations:

In addition, a developer may create an extension of a base type and have it carry augmentation elements, in order to avoid element substitution and flexible content models; whether to substitute or concretely use the elements is at the discretion of the developers and implementers of an information exchange.

The term augmentation describes any element in a NIEM-conformant instance XML document that appears as a result of being substituted for an augmentation point element. Such an element may have a type that is an augmentation type, or it may be a direct element that represents a property.

[Definition: augmentation]

An augmentation is a conformant element information item that:

  1. is an instance of an augmentation element declaration,
  2. is a child of a conformant element information item that is an instance of an augmentable type, and
  3. appears in the instance as a substitution for an augmentation point element.

As an example, here is a definition for nc:PersonType, which includes its augmentation point element:

Figure 10-9: Definition of augmentable type nc:PersonType
<xs:complexType name="PersonType">
+</sch:pattern>

Using the qualifier Association immediately identifies an element as representing an association. This document defines the term association type.

10.4. Augmentations

Developers of domain schemas and other schemas that build on and extend the NIEM release schemas need to be able to define additional characteristics of common types. For example, the JXDM domain, which addresses justice and public safety concerns, considers the following elements to be characteristics of a person, as defined by nc:PersonType:

There are several approaches that could be used by a domain to add elements to a common type. One method is to have each domain create an extension of nc:PersonType (using xs:extension) that adds elements and attributes for the needed content. Some of the problems with this approach include:

This approach turns into a morass that is difficult to use and maintain, and which does not scale to support the breadth of the NIEM community.

To handle this need, NIEM has adopted augmentations. There are several parts that fit together for the definition and use of augmentations:

In addition, a developer may create an extension of a base type and have it carry augmentation elements, in order to avoid element substitution and flexible content models; whether to substitute or concretely use the elements is at the discretion of the developers and implementers of an information exchange.

The term augmentation describes any element in a NIEM-conformant instance XML document that appears as a result of being substituted for an augmentation point element. Such an element may have a type that is an augmentation type, or it may be a direct element that represents a property.

[Definition: augmentation]

An augmentation is a conformant element information item that:

  1. is an instance of an augmentation element declaration,
  2. is a child of a conformant element information item that is an instance of an augmentable type, and
  3. appears in the instance as a substitution for an augmentation point element.

As an example, here is a definition for nc:PersonType, which includes its augmentation point element:

Figure 10-9: Definition of augmentable type nc:PersonType
<xs:complexType name="PersonType">
   <xs:annotation>
     <xs:documentation>A data type for a human being.</xs:documentation>
   </xs:annotation>
diff --git a/publish/niem-ndr.txt b/publish/niem-ndr.txt
index e192bc6..b37632e 100644
--- a/publish/niem-ndr.txt
+++ b/publish/niem-ndr.txt
@@ -3768,7 +3768,7 @@ Rule 10-22. Association element type is an association type
 
       *  j:PersonFBIIdentification
 
-   There are several approaches that could be used to by a domain to add elements to a common type. One method is to have each domain create an extension of nc:PersonType (using xs:extension) that adds elements and attributes for the needed content. Some of the problems with this approach include:
+   There are several approaches that could be used by a domain to add elements to a common type. One method is to have each domain create an extension of nc:PersonType (using xs:extension) that adds elements and attributes for the needed content. Some of the problems with this approach include:
 
       *  It results in numerous, domain-specific specializations of nc:PersonType, each with common content and extension-specific content.
 
diff --git a/src/ndr-doc.xml.m4 b/src/ndr-doc.xml.m4
index 2d50bb2..0a093d1 100644
--- a/src/ndr-doc.xml.m4
+++ b/src/ndr-doc.xml.m4
@@ -5384,7 +5384,7 @@ m4_dnl   MACRO_HAS_DATA_DEFINITION(Schema, sch, xs:schema, A schema document ele
           
  • j:PersonFBIIdentification
    • 
         
 
-        
    There are several approaches that could be used to by a domain to add elements to a common type. One
+        
    There are several approaches that could be used by a domain to add elements to a common type. One
           method is to have each domain create an extension of nc:PersonType
           (using xs:extension) that adds elements and attributes for the needed content. Some of
           the problems with this approach include: