Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adapter.aasx: resolution of file:// references #72

Open
jkhsjdhjs opened this issue Apr 25, 2023 · 6 comments
Open

adapter.aasx: resolution of file:// references #72

jkhsjdhjs opened this issue Apr 25, 2023 · 6 comments
Labels
Specification An issue with the specification rather than our implementation v3.0

Comments

@jkhsjdhjs
Copy link
Contributor

jkhsjdhjs commented Apr 25, 2023

When loading an AASX file, the aasx checks all submodels for File elements and tries to resolve the referenced files relative to the aasx container root. In Version 2.0, a document named TestFile.pdf in the AASX packages root would be referenced by a File element via the path /TestFile.pdf.
Since version 3.0, the schemata prohibit values like /TestFile.pdf and require the file:// protocol to be used, e.g. file:///TestFile.pdf. The problem is that File also supports remote references to files, for example via https://. This isn't allowed by the new schemata.

We should discuss whether the restrictions imposed by the schemata are actually correct, and if so, change the aasx adapter and examples accordingly.

See also:


value='https://www.plattform-i40.de/PI40/Redaktion/DE/Downloads/Publikation/Details-of-the-Asset-'
'Administration-Shell-Part1.pdf?__blob=publicationFile&v=5',

def _collect_supplementary_files(self, part_name: str, submodel: model.Submodel,
file_store: "AbstractSupplementaryFileContainer") -> None:
"""
Helper function to search File objects within a single parsed Submodel, extract the referenced supplementary
files and update the File object's values with the absolute path.
:param part_name: The OPC part name of the part the submodel has been parsed from. This is used to resolve
relative file paths.
:param submodel: The Submodel to process
:param file_store: The SupplementaryFileContainer to add the extracted supplementary files to
"""
for element in traversal.walk_submodel(submodel):
if isinstance(element, model.File):
if element.value is None:
continue
# Only absolute-path references and relative-path URI references (see RFC 3986, sec. 4.2) are considered
# to refer to files within the AASX package. Thus, we must skip all other types of URIs (esp. absolute
# URIs and network-path references)
if element.value.startswith('//') or ':' in element.value.split('/')[0]:
logger.info("Skipping supplementary file %s, since it seems to be an absolute URI or network-path "
"URI reference", element.value)
continue
absolute_name = pyecma376_2.package_model.part_realpath(element.value, part_name)
logger.debug("Reading supplementary file {} from AASX package ...".format(absolute_name))
with self.reader.open_part(absolute_name) as p:
final_name = file_store.add_file(absolute_name, p, self.reader.get_content_type(absolute_name))
element.value = final_name

@s-heppner
Copy link
Contributor

s-heppner commented Apr 26, 2023

Actually, I believe this may be a problem with the specification. In Part 5 Package File Format, it is specified that Submodels should reference supplementary AASX-files via a "relative URI" in the File SubmodelElement.

@s-heppner
Copy link
Contributor

Some further research proves constraint that the file:// prefix is mandatory in the PathType is wrong: PathType Definition. Therefore, it would appear that the schemata is wrong here. I'll look into it.

@s-heppner
Copy link
Contributor

I opened an Issue at aas-core.

@s-heppner
Copy link
Contributor

s-heppner commented Apr 26, 2023

RFC 8089 may not allow for relative paths, have you tried to start with a . though?

@jkhsjdhjs
Copy link
Contributor Author

Thanks for the investigation!

RFC 8089 may not allow for relative paths, have you tried to start with a . though?

I haven't tried that yet, but /TestFile.pdf looks more like an absolute path to me anyways, where / is the root of the AASX package.

@jkhsjdhjs jkhsjdhjs mentioned this issue Aug 24, 2023
26 tasks
@s-heppner s-heppner added Specification An issue with the specification rather than our implementation v3.0 labels Oct 19, 2023
@s-heppner s-heppner added the BlockingRelease This issue needs to be solved before the pending release label Nov 3, 2023
@s-heppner
Copy link
Contributor

As an ugly temporary fix, so that AASX-packages can used, we decided to remove the regex check from the schemata.
We need to document this though and revert these changes with the upcoming spec fix.

s-heppner added a commit to rwth-iat/basyx-python-sdk that referenced this issue Nov 14, 2023
Please note, that according to [eclipse-basyx#72], we decided not
to include the `File` pattern, since the
specification is wrong at this.

[eclipse-basyx#72](eclipse-basyx#72)
s-heppner added a commit that referenced this issue Nov 14, 2023
Please note, that according to [#72], we decided not
to include the `File` pattern, since the
specification is wrong at this.

[#72](#72)
@s-heppner s-heppner removed the BlockingRelease This issue needs to be solved before the pending release label Nov 14, 2023
s-heppner added a commit to aas-core-works/aas-core-meta that referenced this issue Feb 22, 2024
Previously, PathType was matched towards
RFC 8089, however this posed several problems,
such as [basyx-python-sdk#72](eclipse-basyx/basyx-python-sdk#72).

In [aas-specs#299](admin-shell-io/aas-specs#299),
the proposed solution is to make PathType of
type xs:anyURI.

Fixes #303
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Specification An issue with the specification rather than our implementation v3.0
Projects
None yet
Development

No branches or pull requests

2 participants