editorial changes

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

@@ -202,11 +202,11 @@ Typical formats contained are XML and/or JSON.
 Targets any additional file, which is referenced from within the data of an AAS via a relative URI reference in the _File_ submodel element.
 
 ====
-Note 1: the internal relative paths shall be relative to the parent directory of the _rels folder (see ISO/IEC 29500-2).
+Note 1: the internal relative paths shall be relative to the parent directory of the _rels_ folder (see ISO/IEC 29500-2)
 ====
 
 ====
-Note 2: blobs as defined via submodel Element _Blob_ are not stored as supplemental files within the package.
+Note 2: blobs as defined via submodel Element _Blob_ are not stored as supplemental files within the package
 ====
 
 ====
@@ -240,7 +240,7 @@ The file "Thumbnail.png" is referenced in file ".rels" as target for relationshi
 It depicts the content of the AASX package listed in a tree view using the ECMA-376 relationship types defined in <<aasx-rels>> and follows the file name conventions as defined above.
 In this example, it is assumed that the AAS specification files are serialized in XML.
 The data.xml file in this example contains two Asset Administration Shells, two submodels, and a single concept description.
-Three files are referenced within the submodels; they are added to the package in the folder suppl.
+Three files are referenced within the submodels; they are added to the package in the folder "suppl".
 The files can be referenced from both AAS, i.e. from both submodels.
 The same accounts for the concept description that can be used in both submodels.
 The submodels can be part of both AAS, if needed.

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

@@ -15,49 +15,49 @@ SPDX-License-Identifier: CC-BY-4.0
 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.
+<<image-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 Clause <<filtering-export-import>>).
+Instead, some filtering depending on the access and usage policies can be applied before export (see Clause <<image-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.
+In <<image-file-exchange-two-partners>>, it is assumed that import does not need additional filtering.
 
 .Use Case File Exchange between Value Chain Partners
-[[use-case-file-exchange]]
+[[image-use-case-file-exchange]]
 image::use-case-file-exchange.jpeg[]
 
-"Supplier" and "Integrator" form two independent legal bodies (<<file-exchange-two-partners>>).The organizational boundaries as well as the system boundaries including the partners’ infrastructures must be taken into account for data exchange, file exchange being one form of data exchange.
+"Supplier" and "Integrator" form two independent legal bodies (<<image-file-exchange-two-partners>>). The organizational boundaries as well as the system boundaries including the partners’ infrastructures must be taken into account for data exchange, file exchange being one form of data exchange.
 
-The exchange of files needs to fulfil some requirements with respect to usability and security xref:bibliography.adoc#bib12[[12\]].A bilateral agreement on security constraints is required, which must be fulfilled for the transfer and usage of the files.Please refer to Part 4 of the series "Details of the Asset Administration Shell" for more details.
+The exchange of files needs to fulfil some requirements with respect to usability and security xref:bibliography.adoc#bib12[[12\]]. A bilateral agreement on security constraints is required, which must be fulfilled for the transfer and usage of the files. Please refer to Part 4 of the series "Specifications of the Asset Administration Shell" for more details.
 
 .File Exchange between two Value Chain Partners
-[[file-exchange-two-partners]]
+[[image-file-exchange-two-partners]]
 image::file-exchange-two-partners.jpg[]
 
-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.
+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
 
 When exchanging information from partner A to partner B, two use cases may apply.
 
-* The producer of information only wants to submit certain parts of the information.The information might vary depending on the specific consumer it is submitted to.This requires a filtering mechanism, which allows to individually shape the information for the specific consumer.
+* The producer of information only wants to submit certain parts of the information. The information might vary depending on the specific consumer it is submitted to. This requires a filtering mechanism, which allows to individually shape the information for the specific consumer.
 * The consumer of information does not want to include all information provided by the producer in his own process, i.e. he wants to filter only the relevant information.
-+
+
 .Example Filtering for Export and Import
-[[export-import-filter]]
+[[image-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.
+As an example (see <<image-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.
@@ -68,11 +68,11 @@ 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.
+<<image-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]]
 image::example-info-filter.jpg[]
 
 == Basic Concepts of the Open Packaging Conventions

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

@@ -13,7 +13,7 @@ SPDX-License-Identifier: CC-BY-4.0
 The document series "Details of the Asset Administration Shell" specifies the different needs of implementing Asset Administration Shells in an Industry 4.0 environment.
 A corresponding IEC series is in development, see xref:bibliography.adoc#bib13[[13\]].
 
-Besides a technology-neutral specification of the information model in UML, several different formats are provided to exchange Asset Administration Shells: XML, JSON, RDF, AutomationML, as well as an OPC UA information model.
+Besides a technology-neutral specification of the information model in UML, several different formats are provided to exchange Asset Administration Shells, for example XML, JSON and RDF.
 
 <<aas-info-exchange-types>> shows the different ways of exchanging information via Asset Administration Shells.
 This part of the "Details of the Asset Administration Shell" series, Part 5, deals with type 1: file exchange.

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

@@ -54,8 +54,6 @@ In general, normative clauses are characterized by adding the prefix (normative)
 
 Finally, xref:summary-and-outlook.adoc[] summarizes the content and gives an outlook on future work.
 
-The Annex contains additional background information on the exchange format (Annex xref:annex/background.adoc[]).
-
 Metamodel changes compared to previous versions are described in xref:changelog.adoc[].
 
 The bibliography can be found in xref:bibliography.adoc[].