Apply one-sentence-per-line in all adocs

documentation/IDTA-01005/modules/ROOT/pages/annex/background.adoc

@@ -15,13 +15,24 @@ SPDX-License-Identifier: CC-BY-4.0
 The Open Packaging Conventionsfootnote:[Not to be confused with OPC (Open Platform Communication) of the OPC Foundation. Therefore, we will use the full term “Open Packaging Conventions” instead of the abbreviation “OPC”.] format is used as the reference for the Asset Administration Shell package format definition, due to the following reasons.
 
 * Open Packaging Conventions is an international standard specified in ISO/IEC 29500-2:2012 and ECMA-376.
-* Open Packaging Conventions is based on ZIP (as a package container) and XML (for the description of some internal files and definitions). These two technologies are most widely used in their respective domains and are also addressed for long-term archiving.
-* Open Packaging Conventions can be used as package for non-Office applications, too (there are many examples available, such as NuGet, FDI packages, etc.). It provides a logical model independent from how the files are stored in the package. This logical model can be expanded to any sort of application.
+* Open Packaging Conventions is based on ZIP (as a package container) and XML (for the description of some internal files and definitions).
+These two technologies are most widely used in their respective domains and are also addressed for long-term archiving.
+* Open Packaging Conventions can be used as package for non-Office applications, too (there are many examples available, such as NuGet, FDI packages, etc.).
+It provides a logical model independent of how the files are stored in the package.
+This logical model can be expanded to any sort of application.
 * Open Packaging Conventions is also used in the scope of Industry (e.g. FDI packages) and currently in discussion as possible container format for some FDT® and ODVA Project xDS™ use cases.
-* Open Packaging Conventions (and Open Document Format packages) supports digital signing. It can be done for individual files inside of the package. Encryption is not specified in Open Packaging Conventions (it only mentions what shall not be done). Nevertheless, encryption is possible (see points).
+* Open Packaging Conventions (and Open Document Format packages) supports digital signing.
+It can be done for individual files inside the package.
+Encryption is not specified in Open Packaging Conventions (it only mentions what shall not be done).
+Nevertheless, encryption is possible (see points).
 * There are some APIs to handle Open Packaging Conventions packages (Windows API, .NET, Java, etc.) that do not require much knowledge on the technical specification.
-* Open Packaging Conventions encourages chunking, i.e. splitting files into small chunks. This is favorable for reducing the effect of file corruption and better for data access.
-* Some international organizations (e.g. EU, NATO, etc.) recommend using Open Document Format (ISO/IEC 26300-3) instead. However, this recommendation is related to the formats used specifically in Office applications.
-* The Office Open XML and Open Packaging Conventions specifications originated from the Microsoft Corporation and were later standardized as ISO/IEC 29500 and ECMA-376. Current and future versions of ISO/IEC 29500 and ECMA-376 are covered by Microsoft's Open Specification Promise, whereby Microsoft "irrevocably promises" not to assert any claims against those making, using, and selling conforming implementations of any specification covered by the promise (so long as those accepting the promise refrain from suing Microsoft for patent infringement in relation to Microsoft's implementation of the covered specification) xref:bibliography.adoc#bib1[[1\]].
-* Office Open XML (including the Open Packaging Conventions format) and Open Document Format are politically conflicting formats (see details in xref:bibliography.adoc#bib2[[2\]] and xref:bibliography.adoc#bib3[[3\]]). Choosing Open Packaging Conventions as the option for storing the Asset Administration Shell information had only technical reasons based on the arguments mentioned here.
-* Open Packaging Conventions was chosen in favor of iiRDS (v1.0). The scope of iiRDS might not be aligned with the requirements of the Asset Administration Shell, i.e. iiRDS is mainly a format for storing technical documentation of industry devices based on ontology concepts.
+* Open Packaging Conventions encourages chunking, i.e. splitting files into small chunks.
+This is favorable for reducing the effect of file corruption and better for data access.
+* Some international organizations (e.g. EU, NATO, etc.) recommend using Open Document Format (ISO/IEC 26300-3) instead.
+However, this recommendation is related to the formats used specifically in Office applications.
+* The Office Open XML and Open Packaging Conventions specifications originated from the Microsoft Corporation and were later standardized as ISO/IEC 29500 and ECMA-376.
+Current and future versions of ISO/IEC 29500 and ECMA-376 are covered by Microsoft's Open Specification Promise, whereby Microsoft "irrevocably promises" not to assert any claims against those making, using, and selling conforming implementations of any specification covered by the promise (so long as those accepting the promise refrain from suing Microsoft for patent infringement in relation to Microsoft's implementation of the covered specification) xref:bibliography.adoc#bib1[[1\]].
+* Office Open XML (including the Open Packaging Conventions format) and Open Document Format are politically conflicting formats (see details in xref:bibliography.adoc#bib2[[2\]] and xref:bibliography.adoc#bib3[[3\]]).
+Choosing Open Packaging Conventions as the option for storing the Asset Administration Shell information had only technical reasons based on the arguments mentioned here.
+* Open Packaging Conventions was chosen in favor of iiRDS (v1.0).
+The scope of iiRDS might not be aligned with the requirements of the Asset Administration Shell, i.e. iiRDS is mainly a format for storing technical documentation of industry devices based on ontology concepts.

documentation/IDTA-01005/modules/ROOT/pages/basic-concepts-and-leading-picture.adoc

@@ -12,11 +12,22 @@ SPDX-License-Identifier: CC-BY-4.0
 
 == Leading Picture
 
-The leading use case in this document is the exchange of an Asset Administration Shell including all its auxiliary documents and artifacts from one value chain partner to another. This document does not deal with the use case of already deployed Asset Administration Shells running in a specific infrastructure, but only with the file exchange between partners.
-
-<<use-case-file-exchange>> shows the overall picture. It depicts two value chain partners. "Supplier" is going to provide some products, "Integrator" is going to utilize these products to build a machine. Two kinds of Administration Shells are provided: one for the asset with the type of a product (A1, B1 and C1 for the machine), one for the assets with the actual product instances (D1 and D4). The aim is to provide engineering information to the integrator that can be imported into the integrator's engineering system.
-
-The Asset Administration Shells are not necessarily exported "as is". Instead, some filtering depending on the access and usage policies can be applied before export (see <<filtering-export-import>>. The same can happen on the integrator’s side. Not all provided information will necessarily be imported. This is why packages A2 and A3 are distinguished from the original A1 Asset Administration Shell for the product type. The same accounts for B1 and D1. D4 is the composite instance of product type C1.
+The leading use case in this document is the exchange of an Asset Administration Shell including all its auxiliary documents and artifacts from one value chain partner to another.
+This document does not deal with the use case of already deployed Asset Administration Shells running in a specific infrastructure, but only with the file exchange between partners.
+
+<<use-case-file-exchange>> shows the overall picture.
+It depicts two value chain partners.
+"Supplier" is going to provide some products, "Integrator" is going to utilize these products to build a machine.
+Two kinds of Administration Shells are provided: one for the asset with the type of a product (A1, B1 and C1 for the machine), one for the assets with the actual product instances (D1 and D4).
+The aim is to provide engineering information to the integrator that can be imported into the integrator's engineering system.
+
+The Asset Administration Shells are not necessarily exported "as is".
+Instead, some filtering depending on the access and usage policies can be applied before export (see <<filtering-export-import>>.
+The same can happen on the integrator’s side.
+Not all provided information will necessarily be imported.
+This is why packages A2 and A3 are distinguished from the original A1 Asset Administration Shell for the product type.
+The same accounts for B1 and D1.
+D4 is the composite instance of product type C1.
 
 In <<file-exchange-two-partners>>, it is assumed that import does not need additional filtering.
 
@@ -32,7 +43,7 @@ The exchange of files needs to fulfil some requirements with respect to usabilit
 [[file-exchange-two-partners]]
 image::file-exchange-two-partners.jpg[]
 
-For usability sake, a container format is used for file exchange and a corresponding structure is defined.This predefined structure helps the consumer to understand the content of the single files.The container may contain auxiliary files referenced by the AAS or even executable code.
+For usability’s sake, a container format is used for file exchange and a corresponding structure is defined.This predefined structure helps the consumer to understand the content of the single files.The container may contain auxiliary files referenced by the AAS or even executable code.
 
 [#filtering-export-import]
 == Filtering of Information in Export and Import
@@ -46,26 +57,37 @@ When exchanging information from partner A to partner B, two use cases may apply
 [[export-import-filter]]
 image::export-import-filter.jpg[]
 
-As an example (see <<export-import-filter>>), let’s assume that the producer is submitting the complete order data. However, the consumer (in this case the machine builder) is filtering the information (1) and is only importing the information relevant to him. Regarding the functionality, both are filtering: the producer is filtering what he submits to the consumer (2) and the consumer in turn is not using all functionality but is filtering the functionality he wants to use in his environment. The same is possible between machine builders and operators.
-
+As an example (see <<export-import-filter>>), let’s assume that the producer is submitting the complete order data.
+However, the consumer (in this case the machine builder) is filtering the information (1) and is only importing the information relevant to him.
+Regarding the functionality, both are filtering: the producer is filtering what he submits to the consumer (2) and the consumer in turn is not using all functionality but is filtering the functionality he wants to use in his environment.
+The same is possible between machine builders and operators.
 
 ====
-Note: in the use case described above, (i.e. the exchange of information via sharing of xml files, etc.), the information that is not intended for submission needs to be extracted from the corresponding xml files before delivery or before import, respectively. Role or attribute-based access control does not fit this use case. The corresponding access policies might help filtering the corresponding information, but they cannot be submitted as part of the file exchanged.
+Note: in the use case described above, (i.e. the exchange of information via sharing of xml files, etc.), the information that is not intended for submission needs to be extracted from the corresponding xml files before delivery or before import, respectively.
+Role or attribute-based access control does not fit this use case.
+The corresponding access policies might help filtering the corresponding information, but they cannot be submitted as part of the file exchanged.
 ====
 
-
-<<example-info-filter>> shows an example, where the defined xml format is used as defined in this document. The German translation shall not be submitted, only English language is provided to partner B.
+<<example-info-filter>> shows an example, where the defined xml format is used as defined in this document.
+The German translation shall not be submitted, only English language is provided to partner B.
 
 .Example Filtering of Information in XML
 [[example-info-filter]]
 image::example-info-filter.jpg[]
 
 == Basic Concepts of the Open Packaging Conventions
 
-The packaging model specified by the Open Packaging Conventions describes *packages*, *parts*, and *relationships*. Packages hold parts, which hold content and resources, such as *files* footnote:[The term “file” will be used instead of “part”.]. Every file in a package has a unique URI-compliant file name along with a specified content-type expressed in the form of a MIME media type.
+The packaging model specified by the Open Packaging Conventions describes *packages*, *parts*, and *relationships*.
+Packages hold parts, which hold content and resources, such as *files* footnote:[The term “file” will be used instead of “part”.].
+Every file in a package has a unique URI-compliant file name along with a specified content-type expressed in the form of a MIME media type.
 
-Relationships are defined to connect the package to files, and to connect various files in the package. The definition of the relationships (along with the files’ names) is the *logical model* of the package. The resource, i.e. a source of a relationship, must be either the package itself or a data component (file) inside of the package. The target resource of a relationship can be any URI-addressable resource inside or outside of the package. It is possible to have more than one relationship that share the same target file (see example 9–6 in ISO/IEC 29500-2: 2012).
+Relationships are defined to connect the package to files, and to connect various files in the package.
+The definition of the relationships (along with the files’ names) is the *logical model* of the package.
+The resource, i.e. a source of a relationship, must be either the package itself or a data component (file) inside the package.
+The target resource of a relationship can be any URI-addressable resource inside or outside the package.
+It is possible to have more than one relationship that share the same target file (see example 9–6 in ISO/IEC 29500-2: 2012).
 
-The *physical model* maps these logical concepts to a physical format. The result of this mapping is a physical package format (a ZIP archive format) in which files appear in a directory-like hierarchy (adapted from xref:bibliography.adoc#bib4[[4\]] and xref:bibliography.adoc#bib5[[5\]]).
+The *physical model* maps these logical concepts to a physical format.
+The result of this mapping is a physical package format (a ZIP archive format) in which files appear in a directory-like hierarchy (adapted from xref:bibliography.adoc#bib4[[4\]] and xref:bibliography.adoc#bib5[[5\]]).
 
 

documentation/IDTA-01005/modules/ROOT/pages/bibliography.adoc

@@ -12,40 +12,67 @@ SPDX-License-Identifier: CC-BY-4.0
 = Bibliography
 
 [#bib1]
-[1] "Sustainability of Digital Formats: Planning for Library of Congress Collections. Open Packaging Conventions (Office Open XML)", ISO 29500-2:2008-2012, 2012. [Online]. Available: https://www.loc.gov/preservation/digital/formats/fdd/fdd000363.shtml
+[1] "Sustainability of Digital Formats: Planning for Library of Congress Collections.
+Open Packaging Conventions (Office Open XML)", ISO 29500-2:2008-2012, 2012. [Online].
+Available: https://www.loc.gov/preservation/digital/formats/fdd/fdd000363.shtml
 
 [#bib2]
-[2] "Standardization of Office Open XML", Wikipedia. Accessed: 2019-01-26 [Online]. Available: https://en.wikipedia.org/wiki/Standardization_of_Office_Open_XML
+[2] "Standardization of Office Open XML", Wikipedia.
+Accessed: 2019-01-26 [Online].
+Available: https://en.wikipedia.org/wiki/Standardization_of_Office_Open_XML
 
 [#bib3]
-[3] "OpenDocument standardization", Wikipedia. Accessed: 2019-01-26 [Online]. Available: https://en.wikipedia.org/wiki/OpenDocument_standardization
+[3] "OpenDocument standardization", Wikipedia.
+Accessed: 2019-01-26 [Online].
+Available: https://en.wikipedia.org/wiki/OpenDocument_standardization
 
 [#bib4]
-[4] "The Digital Signing Framework of the Open Packaging Conventions". Accessed: 2019-01-26. [Online]. Available: https://msdn.microsoft.com/en-us/library/aa905326.aspx
+[4] "The Digital Signing Framework of the Open Packaging Conventions".
+Accessed: 2019-01-26. [Online].
+Available: https://msdn.microsoft.com/en-us/library/aa905326.aspx
 
 [#bib5]
-[5] "Open Packaging Conventions Fundamentals". Accessed: 2019-01-26 [Online]. Available: https://msdn.microsoft.com/en-us/library/windows/desktop/dd742818(v=vs.85).aspx
+[5] "Open Packaging Conventions Fundamentals".
+Accessed: 2019-01-26 [Online].
+Available: https://msdn.microsoft.com/en-us/library/windows/desktop/dd742818(v=vs.85).aspx
 
 [#bib6]
-[6] "Sustainability of Digital Formats: Planning for Library of Congress Collections. Document Container File: Core (based on ZIP 6.3.3)". Accessed: 2019-01-26. [Online]. Available: https://www.loc.gov/preservation/digital/formats/fdd/fdd000361.shtml
+[6] "Sustainability of Digital Formats: Planning for Library of Congress Collections.
+Document Container File: Core (based on ZIP 6.3.3)".
+Accessed: 2019-01-26. [Online].
+Available: https://www.loc.gov/preservation/digital/formats/fdd/fdd000361.shtml
 
 [#bib7]
-[7] "System.IO.Packaging Namespace", MSDN, Accessed: 2019-01-26 [Online]. Available: https://msdn.microsoft.com/en-us/library/system.io.packaging(v=vs.110).aspx
+[7] "System.IO.Packaging Namespace", MSDN, Accessed: 2019-01-26 [Online].
+Available: https://msdn.microsoft.com/en-us/library/system.io.packaging(v=vs.110).aspx
 
 [#bib8]
-[8] T. Preston-Werner "Semantic Versioning". Version 2.0.0. Accessed: 2020-11-13. [Online]. Available: https://semver.org/spec/v2.0.0.html
+[8] T. Preston-Werner "Semantic Versioning".
+Version 2.0.0. Accessed: 2020-11-13. [Online].
+Available: https://semver.org/spec/v2.0.0.html
 
 [#bib9]
-[9] IDTA-01001 "Specification of the Asset Administration Shell. Part 1: Metamodel". Industrial Digital Twin Assocation. [Online]. Available: https://industrialdigitaltwin.org/en/content-hub/aasspecifications
+[9] IDTA-01001 "Specification of the Asset Administration Shell.
+Part 1: Metamodel".
+Industrial Digital Twin Association. [Online].
+Available: https://industrialdigitaltwin.org/en/content-hub/aasspecifications
 
 [#bib10]
-[10] IDTA-01002 "Specification of the Asset Administration Shell. Part 2: Application Programming Interfaces". Industrial Digital Twin Assocation.  [Online]. Available: https://industrialdigitaltwin.org/en/content-hub/aasspecifications
+[10] IDTA-01002 "Specification of the Asset Administration Shell.
+Part 2: Application Programming Interfaces".
+Industrial Digital Twin Association.  [Online].
+Available: https://industrialdigitaltwin.org/en/content-hub/aasspecifications
 
 [#bib11]
-[11] "Asset Administration Shell. Reading Guide". Industrial Digital Twin Association. [Online]. Available: https://industrialdigitaltwin.org/en/content-hub/downloads
+[11] "Asset Administration Shell.
+Reading Guide".
+Industrial Digital Twin Association. [Online].
+Available: https://industrialdigitaltwin.org/en/content-hub/downloads
 
 [#bib12]
-[12] "Secure Download Service", Discussion Paper. Oct. 2020, Plattform Industrie 4.0. [Online]. Available: https://www.plattform-i40.de/PI40/Redaktion/EN/Downloads/Publikation/secure_downloadservice.html
+[12] "Secure Download Service", Discussion Paper.
+Oct. 2020, Plattform Industrie 4.0. [Online].
+Available: https://www.plattform-i40.de/PI40/Redaktion/EN/Downloads/Publikation/secure_downloadservice.html
 
 [#bib13]
 [13] IEC 63278-1:2023 "Asset Administration Shell for industrial applications – Part 1: Asset Administration Shell structure"