fixing typos and few wrong names (related to SPECITS-33)

sebastian-iancu · sebastian-iancu · commit bc4eb76765fd · 2019-11-03T15:00:04.000+01:00
diff --git a/docs/simplified_data_template.html b/docs/simplified_data_template.html
@@ -290,7 +290,7 @@ <h3 id="_conceptual_approach"><a class="anchor" href="#_conceptual_approach"></a
 <p>The model is accordingly rigorous. However, for some developers who only need to instantiate, commit and/or read relatively limited data-sets, the canonical format can be demanding. This is particularly so for situations in which only a few kinds of data are implicated, i.e. a relatively small number of templates, e.g. vitals signs data, lab results etc.</p>
 </div>
 <div class="paragraph">
-<p>The starting point for defining a developer-friendly commit format is therefore to assume that the great majority of applications are typically targetted to one or a few specific data sets, e.g. vital signs, diabetic monitoring, pregnancy plan etc.</p>
+<p>The starting point for defining a developer-friendly commit format is therefore to assume that the great majority of applications are typically targeted to one or a few specific data sets, e.g. vital signs, diabetic monitoring, pregnancy plan etc.</p>
 </div>
 <div class="paragraph">
 <p>Template-specificity provides a route for defining and generating a serial format such that <em>each openEHR template</em> can be used to define one or more reasonably simple commit formats. Two such formats are discussed here:</p>
@@ -336,7 +336,7 @@ <h3 id="_conceptual_approach"><a class="anchor" href="#_conceptual_approach"></a
 </div>
 </div>
 <div class="paragraph">
-<p>The latter (simSDT) is based on a more radical simplification of the openEHR RM and BASE models, as well as a more programmer-friendly (atural language based) rendering of paths. Under this approach, a lab result data structure could be represented using non-canonical, attribute or tag names such as 'serum_sodium', 'serum_potassium', etc (in English or in any other natural language, including script-based languages), instead of each node appearing under the canonical <code>CLUSTER.<em>items</em></code> attribute and codes like <code>at0001</code>. An example is shown below.</p>
+<p>The latter (simSDT) is based on a more radical simplification of the openEHR RM and BASE models, as well as a more programmer-friendly (natural language based) rendering of paths. Under this approach, a lab result data structure could be represented using non-canonical, attribute or tag names such as 'serum_sodium', 'serum_potassium', etc (in English or in any other natural language, including script-based languages), instead of each node appearing under the canonical <code>CLUSTER.<em>items</em></code> attribute and codes like <code>at0001</code>. An example is shown below.</p>
 </div>
 <div class="listingblock">
 <div class="content">
@@ -371,7 +371,7 @@ <h3 id="_conceptual_approach"><a class="anchor" href="#_conceptual_approach"></a
 </div>
 </div>
 <div class="paragraph">
-<p><strong>A developer just using the simSDT or ncSDT as illustrated above in a specific example-based use case does not necessarily need to understand the detailed steps of conversions described below.</strong> Platforms based on openEHR can have services that generate example instances based on openeEHR templates to make work easier for such developers. The detailed descriptions below are primarily intended for developers creating and maintaining underlying openEHR platforms or dealing with complex use cases.</p>
+<p><strong>A developer just using the simSDT or ncSDT as illustrated above in a specific example-based use case does not necessarily need to understand the detailed steps of conversions described below.</strong> Platforms based on openEHR can have services that generate example instances based on openEHR templates to make work easier for such developers. The detailed descriptions below are primarily intended for developers creating and maintaining underlying openEHR platforms or dealing with complex use cases.</p>
 </div>
 <div class="paragraph">
 <p>To make any form of 'simplified format' work, the following requirements must be met:</p>
@@ -439,7 +439,7 @@ <h3 id="_conceptual_approach"><a class="anchor" href="#_conceptual_approach"></a
 <h2 id="_sopt_generation"><a class="anchor" href="#_sopt_generation"></a>3. sOPT Generation</h2>
 <div class="sectionbody">
 <div class="paragraph">
-<p>This section describes how a Simlified OPT may be machine-derived from its corresponding canonical OPT definition and the Simplified Reference Model (SIM).</p>
+<p>This section describes how a Simplified OPT may be machine-derived from its corresponding canonical OPT definition and the Simplified Reference Model (SIM).</p>
 </div>
 <div class="sect2">
 <h3 id="_visitor_algorithm"><a class="anchor" href="#_visitor_algorithm"></a>3.1. Visitor algorithm</h3>
diff --git a/docs/simplified_data_template/master.adoc b/docs/simplified_data_template/master.adoc
@@ -60,7 +60,7 @@ A significant part of the design ideas and content of this specification was ada
 
 * the Marand 'Web Templates' specification, kindly provided by Better by Marand d.o.o. (Slovenia);
 * the EtherCIS ECISFLAT format by the EtherCIS community, see https://github.com/ethercis/ethercis/blob/master/doc/flat%20json.md;
-* the XSD-based Template Data Schema (TDS) format developed by Ocean Informatics.
+* the XSD-based Template Data Schema (TDS) format developed by Ocean Health Systems.
 
 === Trademarks
 
diff --git a/docs/simplified_data_template/master00-amendment_record.adoc b/docs/simplified_data_template/master00-amendment_record.adoc
@@ -8,7 +8,7 @@
 
 |[[latest_issue]]0.7.0
 |{spec_tickets}/SPECITS-33[SPECITS-33^]. Add Simplified Data Template format specification; +
- Initial writing, adapted from the Marand Better Platform 'Web Templates' specification, EtherCIS documentation and the Ocean Informatics Template Data Schema.
+ Initial writing, adapted from the Marand Better Platform 'Web Templates' specification, EtherCIS documentation and the Ocean Health Systems Template Data Schema.
 |openEHR SEC
 |[[latest_issue_date]]17 Jul 2019
 
diff --git a/docs/simplified_data_template/master02-overview.adoc b/docs/simplified_data_template/master02-overview.adoc
@@ -9,6 +9,6 @@ The default serialised data representations for openEHR content are canonical XM
 * all attributes are named as per the RM, and 
 * all cardinalities respect the RM.
 
-The canonical formats are routinely used by all openEHR implementations implementing the {openehr_ehr_rest_api}[openEHR REST API specification^], and in other ways, e.g. for DB dump/load implementation, ETL and so on. However, creating data instances according to these formats is not always straightforward, particularly for developers with minimal exposure to openEHR, and various alternatives have been used in the past to simplify the job of content creation and committal for application developers. These include TDS/TDD (XSD-based Template Data Schema & Document); and so-called EtherCIS flat JSON and Marand Flat JSON.
+The canonical formats are routinely used by all openEHR implementations implementing the {openehr_ehr_rest_api}[openEHR REST API specification^], and in other ways, e.g. for DB dump/load implementation, ETL and so on. However, creating data instances according to these formats is not always straightforward, particularly for developers with minimal exposure to openEHR, and various alternatives have been used in the past to simplify the job of content creation and committal for application developers. These include TDS/TDD (XSD-based Template Data Schema & Document), and so-called EtherCIS flat JSON and Marand Flat JSON.
 
 This specification responds to the requirement for a complete representation of all of these serial formats within a common formal framework that will permit further variants in the future as and when needed.
diff --git a/docs/simplified_data_template/master03-conceptual.adoc b/docs/simplified_data_template/master03-conceptual.adoc
@@ -11,13 +11,13 @@ The openEHR reference model (RM) and supporting models (BASE component) are desi
 
 The model is accordingly rigorous. However, for some developers who only need to instantiate, commit and/or read relatively limited data-sets, the canonical format can be demanding. This is particularly so for situations in which only a few kinds of data are implicated, i.e. a relatively small number of templates, e.g. vitals signs data, lab results etc.
 
-The starting point for defining a developer-friendly commit format is therefore to assume that the great majority of applications are typically targetted to one or a few specific data sets, e.g. vital signs, diabetic monitoring, pregnancy plan etc. 
+The starting point for defining a developer-friendly commit format is therefore to assume that the great majority of applications are typically targeted to one or a few specific data sets, e.g. vital signs, diabetic monitoring, pregnancy plan etc.
 
 == Historical Formats
 
 Template-specificity provides a route to simplification such that _each openEHR template_ can be used to define one or more reasonably simple commit formats. Three such formats in historical use are:
 
-* _TDS, or Template Data Schema_, an XSD format originally devised by Ocean Informatics;
+* _TDS, or Template Data Schema_, an XSD format originally devised by Ocean Health Systems;
 * _near-canonical RM Simplified Data Template (ncSDT)_, originally devised for the EtherCIS project, see https://github.com/ethercis/ethercis/blob/master/doc/flat%20json.md
 * _simplified IM Simplified Data template (simSDT)_, based on the 'web template' format originally created by Marand for the Better platform, see https://www.ehrscape.com/examples.html
 
@@ -96,7 +96,7 @@ The first of the two JSON formats (ncSDT) is an extract from an Operational Temp
 }
 --------
 
-The latter (simSDT) is based on a more radical simplification of the openEHR RM and BASE models, as well as a more programmer-friendly (atural language based) rendering of paths. Under this approach, a lab result data structure could be represented using non-canonical, attribute or tag names such as 'serum_sodium', 'serum_potassium', etc (in English or in any other natural language, including script-based languages), instead of each node appearing under the canonical `CLUSTER._items_` attribute and codes like `at0001`. An example is shown below.
+The latter (simSDT) is based on a more radical simplification of the openEHR RM and BASE models, as well as a more programmer-friendly (natural language based) rendering of paths. Under this approach, a lab result data structure could be represented using non-canonical, attribute or tag names such as 'serum_sodium', 'serum_potassium', etc (in English or in any other natural language, including script-based languages), instead of each node appearing under the canonical `CLUSTER._items_` attribute and codes like `at0001`. An example is shown below.
 
 [source, json]
 --------
@@ -130,7 +130,7 @@ The latter (simSDT) is based on a more radical simplification of the openEHR RM
 }
 --------
 
-*A developer just using the simSDT or ncSDT as illustrated above in a specific example-based use case does not need to understand the detailed steps of conversions described below.* Platforms based on openEHR can have services that generate example instances based on openeEHR templates to make work easier for such developers. The detailed descriptions below are primarily intended for developers creating and maintaining underlying openEHR platforms or dealing with complex use cases.
+*A developer just using the simSDT or ncSDT as illustrated above in a specific example-based use case does not need to understand the detailed steps of conversions described below.* Platforms based on openEHR can have services that generate example instances based on openEHR templates to make work easier for such developers. The detailed descriptions below are primarily intended for developers creating and maintaining underlying openEHR platforms or dealing with complex use cases.
 
 To make any form of 'simplified format' work, the following requirements must be met:
 
diff --git a/docs/simplified_data_template/master04-sopt_generation.adoc b/docs/simplified_data_template/master04-sopt_generation.adoc
@@ -1,6 +1,6 @@
 = sOPT Generation
 
-This section describes how a Simlified OPT may be machine-derived from its corresponding canonical OPT definition and the Simplified Reference Model (SIM).
+This section describes how a Simplified OPT may be machine-derived from its corresponding canonical OPT definition and the Simplified Reference Model (SIM).
 
 
 == Visitor algorithm
