added xref for figures and clauses

documentation/IDTA-01001/modules/ROOT/pages/includes/valueonly.adoc

@@ -463,8 +463,8 @@ For a BasicEventElement named “MyBasicEvent”, the Value-Only-payload is mini
 === JSON-Schema for the Value-Only Serialization
 
 
-The following JSON-Schema represents the validation schema for the ValueOnly-Serialization of submodel elements. This holds true for all submodel elements mentioned in the previous clause except for _SubmodelElementCollections_. Since _SubmodelElementCollections_ are treated as objects containing submodel elements of any kind, the integration into the same validation schema would result in a circular reference or ambiguous results ignoring the actual validation of submodel elements other than _SubmodelElementCollections_. Hence, the same validation schema must be applied for each _SubmodelElementCollection_ within a submodel element hierarchy. In this case, it may be necessary to create a specific JSON-Schema for the individual use case. The _SubmodelElementCollection_ is added to the following schema for completeness and clarity. It is, however, not referenced from the _SubmodelElementValue_-oneOf-Enumeration due to the reasons mentioned above. +
-See Annex B for an example that validates against this schema.
+The following JSON-Schema represents the validation schema for the ValueOnly-Serialization of submodel elements. This holds true for all submodel elements mentioned in the previous clause except for _SubmodelElementCollections_. Since xref:spec-metamodel/submodel-elements.adoc#submodel-element-collection-attributes[SubmodelElementCollection]s are treated as objects containing submodel elements of any kind, the integration into the same validation schema would result in a circular reference or ambiguous results ignoring the actual validation of submodel elements other than _SubmodelElementCollections_. Hence, the same validation schema must be applied for each _SubmodelElementCollection_ within a submodel element hierarchy. In this case, it may be necessary to create a specific JSON-Schema for the individual use case. The _SubmodelElementCollection_ is added to the following schema for completeness and clarity. It is, however, not referenced from the _SubmodelElementValue_-oneOf-Enumeration due to the reasons mentioned above. +
+See Annex xref:annex/valueonly-serialization-example.adoc[ValueOnly-Serialization Example] for an example that validates against this schema.
 
 [source,json,linenums]
 ----

documentation/IDTA-01001/modules/ROOT/pages/mappings.adoc

@@ -83,7 +83,7 @@ In some use cases only the (model) reference to the object is needed in the firs
 
 References are possible for Referables, only. Potential child elements are ignored.
 
-For references see Clause xref:#_referencing_in_asset_administration_shells[].
+For references see Clause xref:spec-metamodel/referencing.adoc#_referencing_in_asset_administration_shells[Referencing in Asset Administration Shells].
 
 .Format "Reference" - Example in JSON
 [source,json,linenums]
@@ -104,7 +104,7 @@ For references see Clause xref:#_referencing_in_asset_administration_shells[].
 
 The metamodel of an Asset Administration Shell needs to be serialized for import and export scenarios. XML is a possible serialization format.
 
-eXtensible Markup Language (XMLfootnote:[see: https://www.w3.org/TR/2008/REC-xml-20081126/]) is very well suited to derive information from an IT system, e.g. to process it manually and then feed it into another IT system. It meets the needs of the information sharing scenario defined in the leading picture in Clause 4.1. XML provides the possibilities of scheme definitions, which can be used to syntactically validate the represented information in each step.
+eXtensible Markup Language (XMLfootnote:[see: https://www.w3.org/TR/2008/REC-xml-20081126/]) is very well suited to derive information from an IT system, e.g. to process it manually and then feed it into another IT system. XML provides the possibilities of scheme definitions, which can be used to syntactically validate the represented information in each step.
 
 
 ====

documentation/IDTA-01001/modules/ROOT/pages/spec-metamodel/common.adoc

@@ -144,7 +144,7 @@ Note: this is an external reference.
 |xref:spec-metamodel/referencing.adoc#Reference[Reference] |0..* |
 |===
 
-For more details on data specifications, please see Clause 6.
+For more details on data specifications, please see Clause xref:data-specifications.adoc[Data Specification Templates].
 
 == Has Extension Attributes
 
@@ -160,7 +160,7 @@ Element that can be extended by proprietary extensions
 
 
 ====
-Note 1: see Clause 5.3.12.4 for constraints related to extensions.
+Note 1: see Clause xref:spec-metamodel/constraints.adoc#constraints-for-extensions[Constraints for Extensions] for constraints related to extensions.
 ====
 
 
@@ -272,7 +272,7 @@ a|concrete, clearly identifiable element instance. Its creation and validation m
 .Metamodel of Semantic References (HasSemantics)
 image::image18.png[]
 
-For matching algorithm, see Clause 4.4.1.
+For matching algorithm, see Clause xref:general.adoc#matching-strategies-for-semantic-identifiers[Matching Strategies for Semantic Identifiers].
 
 [.table-with-appendix-table]
 [cols="25%,40%,25%,10%"]
@@ -330,9 +330,9 @@ An identifiable element is a referable with a globally unique identifier (_Ident
 
 Non-identifiable referable elements can be referenced. However, this requires the context of the element. A referable that is not identifiable and not child within a SubmodelElementList has a short identifier (_idShort_) that is unique just in its context, its name space.
 
-Information about identification can be found in Clause 4.3. See Clause 4.3.4 for constraints and recommendations on when to use which type of identifier.
+Information about identification can be found in Clause xref:general.adoc#identification-of-elements[Identification of Elements]. See Clause xref:general.adoc#which-identifiers-for-which-elements[Which Identifiers for Which Elements?] for constraints and recommendations on when to use which type of identifier.
 
-See Clause 4.3.4 for information about which identifier types are supported.
+See Clause xref:general.adoc#which-identifiers-for-which-elements[Which Identifiers for Which Elements?] for information about which identifier types are supported.
 
 [.table-with-appendix-table]
 [cols="25%,40%,25%,10%"]
@@ -386,7 +386,7 @@ A qualifiable element may be further qualified by one or more qualifiers.
 
 
 ====
-Note: see Clause 5.3.12.3 for constraints related to qualifiables.
+Note: see Clause xref:spec-metamodel/constraints.adoc#constraints-for-qualifiers[Constraints for Qualifiers] for constraints related to qualifiables.
 ====
 
 
@@ -517,11 +517,11 @@ image::image23.png[]
 
 The metamodel differentiates between elements that are identifiable, referable, or none of both. The latter means they are neither inheriting from _Referable_ nor from _Identifiable_, which applies e.g. to __Qualifier__s.
 
-Referable elements can be referenced via the _idShort_ (with exception of elements within a SubmodelElementList). For details on referencing, see Clause 5.3.9.
+Referable elements can be referenced via the _idShort_ (with exception of elements within a xref:spec-metamodel/submodel-elements.adoc#submodel-element-list-attributes [SubmodelElementList]). For details on referencing, see Clause xref:spec-metamodel/referencing.adoc[Referencing in Asset Administration Shells].
 
 Not every element of the metamodel is referable. There are elements that are just attributes of a referable.
 
-The __idShort__ shall be unique in its name space for non-identifiable referables (exception: referables within a SubmodelElementList) (see Constraint AASd-022). A name space is defined as follows in this context: the parent element(s), which an element is part of and that is either referable or identifiable, is the name space of the element. Examples: a submodel is the name space for the properties directly contained in it; the name space of a submodel element contained in a submodel element collection is the submodel element collection.
+The __idShort__ shall be unique in its name space for non-identifiable referables (exception: referables within a xref:spec-metamodel/submodel-elements.adoc#submodel-element-list-attributes [SubmodelElementList]) (see Constraint AASd-022). A name space is defined as follows in this context: the parent element(s), which an element is part of and that is either referable or identifiable, is the name space of the element. Examples: a submodel is the name space for the properties directly contained in it; the name space of a submodel element contained in a submodel element collection is the submodel element collection.
 
 [.table-with-appendix-table]
 [cols="25%,40%,25%,10%""]
@@ -532,7 +532,7 @@ Note1 : an element that is referable by its idShort. This ID is not globally uni
 
 
 ====
-Note 2: see Clause 5.3.12.2 for constraints related to referables.
+Note 2: see Clause xref:spec-metamodel/constraints.adoc#constraints-for-referables-and-identifiables[Constraints for Referables and Identifiables] for constraints related to referables.
 ====
 
 

documentation/IDTA-01001/modules/ROOT/pages/spec-metamodel/core.adoc

@@ -17,7 +17,7 @@ image::image24.png[]
 
 An Administration Shell is uniquely identifiable since it inherits from _Identifiable_.
 
-The _derivedFrom_ attribute is used to establish a relationship between two Asset Administration Shells that are derived from each other. For more detailed information on the _derivedFrom_ concept, see Clause 4.2.
+The _derivedFrom_ attribute is used to establish a relationship between two Asset Administration Shells that are derived from each other. For more detailed information on the _derivedFrom_ concept, see Clause xref:general.adoc#types-and-instances[Types and Instances].
 
 [.table-with-appendix-table]
 [cols="25%,40%,25%,10%"]
@@ -69,7 +69,7 @@ The asset has a globally unique identifier, plus – if needed – additional do
 
 
 ====
-Note: see Clause 5.3.12.5 for constraints related to asset information.
+Note: see Clause xref:spec-metamodel/constraints.adoc#constraints-for-asset-related-information[Constraints for Asset-Related Information] for constraints related to asset information.
 ====
 
 
@@ -172,7 +172,7 @@ a|Neither a type asset nor an instance asset nor a role asset
 
 |===
 
-For more information on types and instances, see Clause 4.2.
+For more information on types and instances, see Clause xref:general.html#types-and-instances[Types and Instances].
 
 [.table-with-appendix-table]
 [cols="25%,40%,25%,10%"]

documentation/IDTA-01001/modules/ROOT/pages/spec-metamodel/datatypes.adoc

@@ -17,7 +17,7 @@ as its basic data types footnote:[https://www.w3.org/XML/Core/, former https://w
 
 The meaning and format of xsd types is specified in XML Schema 1.0 (https://www.w3.org/TR/xmlschema-2). The simple type "langString" is specified in the Resource Description Framework (RDF) footnote:[see: https://www.w3.org/TR/rdf11-concepts/].
 
-See Clause 5.3.12.6 for constraints on types.
+See Clause xref:spec-metamodel/constraints.adoc#constraints-for-types[Constraints for Types] for constraints on types.
 
 .Simple Data Types Used in Metamodel
 [cols="10%,19%,38%,33%",options="header",]
@@ -56,7 +56,7 @@ Table 8 lists the Primitives used in the metamodel. Primitive data types start w
 
 
 ====
-Note: see Clause 5.3.12.6 for constraints on types.
+Note: see Clause xref:spec-metamodel/constraints.adoc#constraints-for-types[Constraints for Types] for constraints on types.
 ====
 
 

documentation/IDTA-01001/modules/ROOT/pages/spec-metamodel/referencing.adoc

@@ -31,7 +31,7 @@ Note: references should not be mixed up with locators. Even URLs can be used as
 .Metamodel of Reference
 image::image48.png[]
 
-See Clause 4.4.2 for reference matching.
+See Clause xref:general.adoc#matching-algorithm-for-references[Matching Algorithm for References] for reference matching.
 
 [.table-with-appendix-table]
 [cols="25%,40%,25%,10%"]
@@ -792,7 +792,7 @@ identifiers for the corresponding resource referenced.
 {aasd128}
 
 In the following examples for valid und invalid model references and external references are given.
-The notation follows the grammar as defined in Clause xref:#_serialization_of_values_of_type_reference[].
+The notation follows the grammar as defined in Clause xref:mappings.adoc#_serialization_of_values_of_type_reference[Text Serialization of Values of Type "Reference"].
 
 [.underline]#Examples for valid references:#
 

documentation/IDTA-01001/modules/ROOT/pages/spec-metamodel/submodel-elements.adoc

@@ -245,7 +245,7 @@ For more information on the concept of subject, see Attribute Based Access Contr
 .Metamodel of Blobs
 image::image32.png[]
 
-For information on content type, see Clause 5.3.7.9 on submodel element "File".
+For information on content type, see Clause xref:spec-metamodel/submodel-elements.adoc#file-attributes[File Attributes].
 
 [.table-with-appendix-table]
 [cols="25%,40%,25%,10%"]
@@ -659,7 +659,7 @@ h|Explanation h|Type h|Card.
 a|External reference to an external object or entity or a logical reference to another element within the same or another Asset Administration Shell (i.e. a model reference to a _Referable_) |xref:Reference[Reference] |0..1
 |===
 
-For more information on references, see Clause 5.3.9.
+For more information on references, see Clause xref:spec-metamodel/referencing.adoc[Referencing in Asset Administration Shells].
 
 == Relationship Element Attributes
 
@@ -699,7 +699,7 @@ Note: the different elements of a submodel element collection do not have to hav
 ====
 
 
-Example: a single document has a predefined set of properties like title, version, author, etc. They logically belong to a document. So a single document is represented by a _SubmodelElementCollection_. An asset usually has many different documents available like operating instructions, safety instructions, etc. The set of all documents is represented by a _SubmodelElementList_ (see Clause _5.3.7.17)_. In this case, we have a _SubmodelElementList_ of __SubmodelElementCollection__s.
+Example: a single document has a predefined set of properties like title, version, author, etc. They logically belong to a document. So a single document is represented by a _SubmodelElementCollection_. An asset usually has many different documents available like operating instructions, safety instructions, etc. The set of all documents is represented by a xref:spec-metamodel/submodel-elements.adoc#submodel-element-list-attributes[SubmodelElementList]. In this case, we have a xref:spec-metamodel/submodel-elements.adoc#submodel-element-list-attributes[SubmodelElementList] of xref:spec-metamodel/submodel-elements.adoc#submodel-element-collection-attributes[SubmodelElementCollection]s.
 
 
 ====
@@ -739,7 +739,7 @@ Submodel element lists are also used to create multi-dimensional arrays. A two-d
 
 Similarly, a table with three columns can be represented. In this case a _SubmodelElementCollection_ with three _SubmodelElementLists_ would be contained and the _semanticId_ as well as the _semanticIdListElement_ for the three columns would differ.
 
-Matching strategies for semantic IDs are explained in Clause 4.4.1.
+Matching strategies for semantic IDs are explained in Clause xref:general.adoc#matching-strategies-for-semantic-identifiers[Matching Strategies for Semantic Identifiers].
 
 [.table-with-appendix-table]
 [cols="25%,40%,25%,10%"]