SME File/value for relative Path to files in .aasx

[BirgitBoss]

Is your feature request related to a problem? Please describe.
Discussion and request from TF Part1 of Work Stream "Specification of the AAS":

• it should be clarified how exactly a relative path to an existing file in the .aasx file within the data.xml or data.json file as value of a submodel element "File" should be made.

compare also to discussion in admin-shell-io/aas-specs#299, comment admin-shell-io/aas-specs#299 (comment)

Note: This issue is different to #3: In #3 it is about relative path within predefined files of OPC format itself (i.e. in rels-files). This issue is about the AAS data file and its File Submodel element. It is stated in Part 5, V3.0 that File/value may contain a relative path that is referencing a file (aas-suppl) the .aasx file

[alexgordtop]

Today we started a discussion in "02-1 TF Interoperability...", where we raised the issue, that a relation between file.value and the binary content held by the system, may lead to unexpected behavior.

Please understand this comment as a request for discussion!
It's not a final solution and the solution proposal is not aligned with the TF.

Please download and review the two attached aasx files, where I added the README.md from our two specification repositories as a File SubmodelElement.
two_sample_aasx_files.tgz

In the example, there are two shells (id="admin-shell.io/aas-specs" and id="admin-shell.io/aas-specs-api") with one submodel each.
The Submodels have a File SubmodelElement with idShort "readme" and value "/aasx/files/README.md".

This example may simulate many use cases, where a business process defines folder structures and file names, while the file identity is defined by the whole path (folder structure + filename).

When uploading such a file in e.g. AASX Package Explorer (which I did here), everything seems to be fine, since a AAS in its own package doesn't care about other packages. The same applies to package less systems, where AAS are stored in databases or similar systems.

Challenge:
In this situation it's a little tricky to export these two shells into one AASX file - since there is an overlap between the two files...

The structure inside the AASX is as follows:

/[Content_Types].xml
/_rels/...
/aasx/aas_specs.aas.xml -> The AasEnv serialized as xml with all the shell/submodels/...
/aasx/_rels/aas_specs.aas.xml.rels -> Mapping between a logical key and the file-payload to be transported
/aasx/files/README.md -> Here we would face an overlap!

Here is the "aasx/_rels/aas_specs.aas.xml.rels" content:

<?xml version="1.0" encoding="utf-8"?>
<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
    <Relationship Type="http://www.admin-shell.io/aasx/relationships/aas-suppl" Target="/aasx/files/README.md" Id="R20b9932757ae4357" />
</Relationships>

-> The Id is the logical key and Target is path inside aasx, where the payload is stored.

From my understanding it gets really tricky, if the Target is aligned with file.value - because we then have overlapping paths for two binary distinct file-payloads. The "readme"s of our two specifications are not the same!

From my understanding, there is a misconception in the specification or implementation, when we try to align File.value and Relationship.Target -> because that way we make the indirection between the logical Relationship and the Target-Payload bloody useless.
Wouldn't it be much better to relate Relationship.ID and the File-SubmodelElement with each other - and let the Relationship.Target be the same for the intentionally same binary file payload and two different not matching payloads?

We could use as Relationship.ID something, that is based on the qualified path like <submodel_id>/ and as Relationship.Target something like "/assx/files/<base64url_encoded_sm_id>/<id_short_path>".

If a file is shared between two submodels, then the Target could be something like "/aasx/files/shared/".
With two "Relationship"-Entries, pointing to the same Target.
The ID attribute is the logical link to "<submodel_id>/" and Target documents explicitly, if the content is shared by intention - or not.

Relationship.ID could be "<base64url_encoded_sm_id>/<id_short_path>" or a hash of that or something else - I actually don't know the constraints that apply to this ID, yet.