Update SSP Traceability to be based on SSP 2.0-rc.1

Update references and sub-module, remove now duplicated meta-data
related types in STC.xsd, adjust documentation.

specification/0___preamble.adoc

@@ -1,6 +1,6 @@
-The SSP Traceability Specification is a free specification intended as a third-party layered standard upon SSP 1.0 to support traceability of simulation tasks.
+The SSP Traceability Specification is a free specification intended as a third-party layered standard upon SSP 2.0 to support traceability of simulation tasks.
 This is a development version of the specification.
-https://github.com/PMSFIT/SSPTraceability/releases[Releases] and https://github.com/PMSFIT/SSPTraceability/issues[issues] can be found on https://github.com/PMSFIT/SSPTraceability[github.com/PMSFIT/SSPTraceability].
+https://github.com/modelica/ssp-ls-traceability/releases[Releases] and https://github.com/modelica/ssp-ls-traceability/issues[issues] can be found on https://github.com/modelica/ssp-ls-traceability[github.com/modelica/ssp-ls-traceability].
 
 {empty} +
 {empty}

specification/10___literature.adoc

@@ -7,6 +7,8 @@
 
 - [[[SSP10]]] Modelica Association: **System Structure and Parameterization 1.0**. March 2019. https://ssp-standard.org/publications/SSP10/SystemStructureAndParameterization10.pdf
 
+- [[[SSP20]]] Modelica Association: **System Structure and Parameterization 2.0-rc.1**. October 2024. https://github.com/modelica/ssp-standard/releases/download/v2.0-rc.1/SSP-Specification.zip
+
 - [[[XMLSCHEMA1.1]]] World Wide Web Consortium, Inc. (W3C): **XML Schema 1.1**. April 2012. https://www.w3.org/XML/Schema
 
 - [[[XLINK]]] World Wide Web Consortium, Inc. (W3C): **XLink 1.1**. May 2010. https://www.w3.org/TR/xlink/

specification/3___overview.adoc

@@ -18,7 +18,7 @@ The form in which this bundle exists, e.g. whether it is stored as a file or in
 * File-based resources linked by a GlueParticle file should be exchanged with the GlueParticle file itself to **take full advantage** of the GlueParticle transfer.
 
 NOTE: Although the idea of the GlueParticle approach does not depend on a specific data format or representation in general, the SSP Traceability Specification defines a set of data formats for the file-based representation of a GlueParticle content, i.e. process-relevant information and resources.
-The reason for this is firstly that the Modelica Association uses XML as a general encoding format for the representation of standards specific data and secondly that SSP Traceability uses System Structure and Parameterization (SSP) Standard 1.0 resources and concepts that are also encoded in XML.
+The reason for this is firstly that the Modelica Association uses XML as a general encoding format for the representation of standards specific data and secondly that SSP Traceability uses System Structure and Parameterization (SSP) Standard 2.0 resources and concepts that are also encoded in XML.
 Independently of this, SSP Traceability files in general and GlueParticle files in particular could use any other applicable data encoding format, e.g. JSON etc.
 
 The SSP Traceability specification specifies a set of data formats that can be used to document or link process-relevant information and resources for a Credible Decision Process and a Credible Simulation Process introduced in <<sec-crediblesimulationprocessframework>>.
@@ -138,7 +138,7 @@ One of the boundary conditions refer to the packaging format.
 GlueParticles, by their nature, are not self-contained, but reference many resources that they tie together in their function as GlueParticles.
 Packaging GlueParticles together with their referenced resources into easily exchangeable packages is therefore of fundamental importance.
 
-The current packaging approach is based on the SSP 1.0 standard, which also serves as the basis for other aspects.
+The current packaging approach is based on the SSP 2.0 standard, which also serves as the basis for other aspects.
 <<sec-ssptraceabilitypackaging>> details how GlueParticles can be packaged in SSP archives, either standalone or in a way that allows these archives to be treated as native SSP packages by SSP-aware processors.
 Ways to package GlueParticles in other container formats such as FMUs are also specified.
 

specification/5___stc.adoc

@@ -316,7 +316,7 @@ The LifeCycleEntryType element is structured by the following subordinated eleme
 | Sub element name     | Optional / Mandatory | Details
 | GResourceOrReference | Optional             | <<sec-gresourceorreference>>
 | Responsible          | Mandatory            | <<sec-responsibletype>>
-| Signature            | Optional             | <<sec-signaturetype>>
+| Signature            | Optional             | See SSP Specification
 | GElementCommon       | Optional             | <<sec-gelementcommon>>
 |===
 
@@ -558,10 +558,10 @@ The ResourceType element is structured by the following subordinated elements.
 [width="100%",options="header"]
 |===
 | Sub element name | Optional / Mandatory | Details
-| Content          | Optional             | <<sec-contenttype>>
+| Content          | Optional             | See SSP Specification
 | Summary          | Optional             | <<sec-summary>>
-| Metadata         | Optional             | <<sec-metadata>>
-| Signature        | Optional             | <<sec-signaturetype>>
+| ssc:Metadata     | Optional             | See SSP Specification
+| ssc:Signature    | Optional             | See SSP Specification
 | GElementCommon   | Optional             | <<sec-gelementcommon>>
 |===
 
@@ -634,8 +634,8 @@ The Summary element is structured by the following subordinated elements.
 [width="100%",options="header"]
 |===
 | Sub element name | Optional / Mandatory | Details
-| Content          | Optional             | <<sec-contenttype>>
-| Signature        | Optional             | <<sec-signaturetype>>
+| Content          | Optional             | See SSP Specification
+| Signature        | Optional             | See SSP Specification
 | GElementCommon   | Optional             | <<sec-gelementcommon>> 
 |===
 
@@ -651,102 +651,6 @@ The Summary element is associated with the following attributes.
 | sourceBase     | Optional             | Defines the base the source URI is resolved against: If the attribute is missing or is specified as GlueParticle, the source is resolved against the URI of the GlueParticle, if the attribute is specified as resource the URI is resolved against the (resolved) URI of the resource source. 
 |===
 
-[#sec-metadata]
-==== MetaData
-
-The MetaData element can specify additional metadata for the given resource. Multiple (or no) MetaData elements may be present.
-
-[#im-metadataschema]
-.MetaData element structure and attributes
-image::MetaDataSchema.png[]
-
-The MetaData element is structured by the following subordinated elements.
-
-[#tb-metadatasubelements]
-.MetaData element structure
-[width="100%",options="header"]
-|===
-| Sub element name | Optional / Mandatory |  Details
-| Content          | Optional             | <<sec-contenttype>>
-| Signature        | Optional             | <<sec-signaturetype>>
-| GElementCommon   | Optional             | <<sec-gelementcommon>> 
-|===
-
-The MetaData element is associated with the following attributes.
-
-[#tb-metadataattributes]
-.MetaData element attributes
-[width="100%",options="header"]
-|===
-| Attribute name | Optional / Mandatory | Attribute description
-| kind           | Mandatory           | This attribute indicates the kind of resource meta data that is referenced, i.e. what role it plays in relation to the resource being described. 
-| type           | Mandatory           | This mandatory attribute specifies the MIME type of the resource meta data, which does not have a default value. If no specific MIME type can be indicated, then the type application/octet-stream is to be used.
-| source         | Optional            | This attribute indicates the source of the resource meta data as a URI (cf. RFC 3986). For purposes of the resolution of relative URIs the base URI is the URI of the GlueParticle, if the sourceBase attribute is ot specified or is specified as GlueParticle, and the URI of the referenced resource if the sourceBase attribute is specified as resource. This allows the specification of meta data sources that reside inside the resource (e.g. an FMU) through relative URIs. For meta data that are located alongside the GlueParticle, relative URIs without scheme and authority can and should be used to specify the meta data sources.  For meta data that are packaged inside an SSP that contains this GlueParticle, this is mandatory (in this way, the GlueParticle URIs remain valid after unpacking the SSP into the file system). If the source attribute is missing, the meta data is provided inline as contents of the Content element, which must not be present otherwise. 
-| sourceBase     | Optional            | Defines the base the source URI is resolved against:  If the attribute is missing or is specified as GlueParticle, the source is resolved against the URI of the GlueParticle, if the attribute is specified as resource the URI is resolved against the (resolved) URI of the resource source.
-|===
-
-[#sec-signaturetype]
-=== SignatureType
-
-The SignatureType element defines the structure and attributes of the signature entity for a given step or phase.
-
-[#im-signaturetypeschema]
-.SignatureType element structure and attributes
-image::SignatureTypeSchema.png[]
-
-The SignatureType element is structured by the following subordinated elements.
-
-[#tb-signaturetypesubelements]
-.SignatureType element structure
-[width="100%",options="header"]
-|===
-| Sub element name | Optional / Mandatory |  Details
-| Content          | Optional             | <<sec-contenttype>>
-| GElementCommon   | Optional             | <<sec-gelementcommon>> 
-|===
-
-The SignatureType element is associated with the following attributes.
-
-[#tb-signaturetypeattributes]
-.SignatureType element attributes
-[width="100%",options="header"]
-|===
-| Attribute name | Optional / Mandatory | Attribute description
-| role           | Mandatory           | This mandatory attribute specifies the role this signature has in the overall process. It indicates whether the digital signature is intended to just convey the authenticity of the information, or whether a claim for suitability of the information for certain purposes is made.  In the latter case, the digital signature format should include detailed information about what suitability claims are being made.
-| type           | Mandatory           | This mandatory attribute specifies the MIME type of the resource signature, which does not have a default value.  If no specific MIME type can be indicated, then the type application/octet-stream is to be used.
-| source         | Optional            | This attribute indicates the source of the resource signature as a URI (cf. RFC 3986).  For purposes of the resolution of relative URIs the base URI is the URI of the GlueParticle, if the sourceBase attribute is not specified or is specified as GlueParticle, and the URI of the referenced resource if the sourceBase attribute is specified as resource. This allows the specification of signature sources that reside inside the resource (e.g. an FMU) through relative URIs. For signatures that are located alongside the GlueParticle, relative URIs without scheme and authority can and should be used to specify the signature sources. For signatures that are packaged inside an SSP that contains this GlueParticle, this is mandatory (in this way, the GlueParticle URIs remain valid after unpacking the SSP into the filesystem). If the source attribute is missing, the signature is provided inline as contents of the Content element, which must not be present otherwise. 
-| sourdceBase    | Optional            | Defines the base the source URI is resolved against:  If the attribute s missing or is specified as GlueParticle, the source is resolved against the URI of the GlueParticle, if the attribute is specified as resource the URI is resolved against the (resolved) URI of the resource source.
-|===
-
-
-[#sec-contenttype]
-=== ContentType
-
-The ContentType element defines the structure and attributes of inline content of an entity.
-If it is present, then the attribute source of the enclosing element must not be present.
-
-[#im-contenttypeschema]
-.ContentType element structure and attributes
-image::ContentTypeSchema.png[]
-
-The ContentType element is structured by following subordinated elements.
-
-[#tb-contenttypesubelements]
-.ContentType element structure 
-[width="100%",options="header"]
-|===
-| Sub element name     | Optional / Mandatory |  Details
-| ##any                | Optional             | <<sec-any03>>
-|===
-
-The ContentType is not associated with any specific attributes beyond the common SSP attributes.
-
-[#sec-any03]
-==== ##any
-
-The ContentType may contain XML Elements of any kind, i.e. the it provides the possibility and capability to code any kind of information regardless of what the Schema specifies.
-This mean the name, structure and attributes of XML elements enclosed by a contentType element is completely free.
-
 
 [#sec-responsibletype]
 === ResponsibleType

specification/9___packaging.adoc

@@ -12,18 +12,18 @@ and other resources using the SSP packaging format.
 The current specification specifies the packaging of simulation task
 meta-data files together with all referenced system descriptions,
 models, parameters, their meta-data, simulation results and other
-resources in SSP 1.0 package files as a layered standard based on SSP
-1.0.
+resources in SSP 2.0 package files as a layered standard based on SSP
+2.0.
 
 By basing the packaging on the SSP standard, it is possible to treat
 STMD containing SSP packages as normal SSP packages for use in tools
 that do not yet support STMD-based work flows. Furthermore this
 approach simplifies the definition of STMD-based packages by reusing
 the built-in functionality of the SSP standard.
 
-=== SSP 1.0
+=== SSP 2.0
 
-Any STMD-based package MUST be a valid _SSP 1.0_ <<SSP10>> SSP archive.
+Any STMD-based package MUST be a valid _SSP 2.0_ <<SSP20>> or _SSP 1.0_ <<SSP10>> SSP archive.
 Inter alia this means that it MUST contain at least one SSD file named
 `SystemStructure.ssd` in the root of the archive, which MUST be a valid
 system structure description file. In phases of the simulation task