SDPi Prepublication edits Rev. 2.4.0

CHANGELOG.md

@@ -18,6 +18,12 @@ Each section shall contain a list of action items of the following format: `<bri
 ## Unreleased
 -->
 
+## [2.4.1] - 2026-05-07
+
+### Editorial Fixes
+
+- IHE Publications changes for SDPi 2.4 publication ("e.g., " punctuation) ([PR#526](https://github.com/IHE/DEV.SDPi/pull/526))
+
 ## [2.4.0] - 2026-04-01
 
 ### Added

asciidoc/volume3/biceps-content-module/tf3-ch-8.3.2.9.1-extension-constraints.adoc

@@ -22,7 +22,7 @@ Some XML processor APIs do not support ordered access to XML _mixed content_, wh
 </foo>
 ----
 
-There are APIs that do not fully implement the XML Document Object Model and hence cannot individually access text nodes (e.g. as in <<vol3_clause_extension_constraints_interlaced>>: "Here", "is some", "interlaced", and "text") in between the interlaced elements but only as concatenated text.
+There are APIs that do not fully implement the XML Document Object Model and hence cannot individually access text nodes (e.g., as in <<vol3_clause_extension_constraints_interlaced>>: "Here", "is some", "interlaced", and "text") in between the interlaced elements but only as concatenated text.
 This makes verification measures unnecessarily complicated.
 As mixed content is not required to be available in device to device communication, <<r0019>> prohibits the use of mixed content types in BICEPS extensions.
 

asciidoc/volume3/tf3-ch-8.3.2-biceps-content.adoc

@@ -161,13 +161,13 @@ The <<ref_ieee_11073_10700_2022>> Base Requirements for Participants in a Servic
 
 NOTE: This implies that a MANUFACTURER that needs to use private codes has to keep a private coding system for these codes. Following the concept of private codes that is defined in <<ref_ieee_11073_10101_2020>>, a MANUFACTURER introduces and maintains a set of codes that adhere to the principles of the <<ref_ieee_11073_10101_2020>> nomenclature standards.
 
-There are different ways to define a globally unique identifier for the vendor-specific private coding system (e. g. URL, OID, etc.). In the context of medical device interoperability, the recommendation is to use  an "object identifier" (OID) for private codes as detailed in <<ref_ieee_11073_10101_2020>> and other purposes (e. g. private SDC extensions):
+There are different ways to define a globally unique identifier for the vendor-specific private coding system (e.g., URL, OID, etc.). In the context of medical device interoperability, the recommendation is to use  an "object identifier" (OID) for private codes as detailed in <<ref_ieee_11073_10101_2020>> and other purposes (e.g., private SDC extensions):
 
-* Compared with other identifiers (e.g. URLs) OIDs are very compact, which helps to keep the size of data messages low
+* Compared with other identifiers (e.g., URLs) OIDs are very compact, which helps to keep the size of data messages low
 
 * It is free of charge to register a globally unique enterprise OID with https://www.iana.org/assignments/enterprise-numbers/assignment/apply/[IANA].
 
-An enterprise OID assigned by IANA always starts with the prefix *iso.org.dod.internet.private.enterprise (1.3.6.1.4.1)*. The actual enterprise node number, which follows the prefix, is globally unique to the medical device vendor (e. g. "_1.3.6.1.4.1.12345_" for the *Medical Device XYZ Ltd.* company).
+An enterprise OID assigned by IANA always starts with the prefix *iso.org.dod.internet.private.enterprise (1.3.6.1.4.1)*. The actual enterprise node number, which follows the prefix, is globally unique to the medical device vendor (e.g., "_1.3.6.1.4.1.12345_" for the *Medical Device XYZ Ltd.* company).
 
 Once the enterprise OID is registered, it is up to the medical device vendor to extend the OID by adding child nodes. The child nodes don't have a globally unique meaning, but the enterprise OID plus the child nodes are required to be globally unique. It is recommended to define a child node schema, and assign unique numbers to the concepts on each node level.
 

asciidoc/volume3/tf3-ch-8.3.2.13-metric-display-precision.adoc

@@ -40,7 +40,7 @@ If the metric *@Value* falls in one of the *pm:TechnicalRange* elements and in o
 
 *For Metric @Samples*:
 
-For metric *@Samples*, it is possible that individual samples fall in different *pm:TechnicalRange* or *pm:PhysiologicalRange* elements. In this case the <<actor_somds_consumer>> has to decide which of the *pm:TechnicalRange* or *pm:PhysiologicalRange* element is considered as the _active range_ (*pm:Range* element) for the entire set of samples currently utilized for displaying - e.g. *Airway Pressure* wave displayed with the highest precision defined by the _active range_ at the consumer's screen.
+For metric *@Samples*, it is possible that individual samples fall in different *pm:TechnicalRange* or *pm:PhysiologicalRange* elements. In this case the <<actor_somds_consumer>> has to decide which of the *pm:TechnicalRange* or *pm:PhysiologicalRange* element is considered as the _active range_ (*pm:Range* element) for the entire set of samples currently utilized for displaying - e.g., *Airway Pressure* wave displayed with the highest precision defined by the _active range_ at the consumer's screen.
 
 If an individual sample falls in one of the *pm:TechnicalRange* elements and in one of *pm:PhysiologicalRange* elements at the same time, the *pm:PhysiologicalRange* element of the metric state will supersede the *pm:TechnicalRange* element of the descriptor and will become the _active range_ for this particular sample.