-
Notifications
You must be signed in to change notification settings - Fork 24
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
Attaching files with spaces in the file name causes a ValueError when writing the AASX #236
Comments
More details: def check_part_name(part_name: str) -> None:
""" Check if `part_name` is a valid OPC part name in URI (not IRI) representation.
:raises ValueError: if it is not.
"""
if not RE_PART_NAME.match(part_name):
raise ValueError("{} is not an URI path with multiple segments (each not empty and not starting with '.') "
"or not starting with '/' or ending wit '/'".format(repr(part_name))) And RE_PART_NAME = re.compile(r'^(/[A-Za-z0-9\-\._~%:@!$&\'()*+,;=]*[A-Za-z0-9\-_~%:@!$&\'()*+,;=])+$') Let's first conclude that The first bracket expression contains the Other than that, I don't have enough knowledge to judge whether ECMA 376 allows spaces in file names or not. |
OPC Specification IMHO is here: https://standards.iso.org/ittf/PubliclyAvailableStandards/c077818_ISO_IEC_29500-2_2021(E).zip The relevant chapter seems to be 6.2.2 Part Names. And 6.2.2.2 Syntax specifies:
So this is really about ending with a dot. Furthermore:
So it seems to me that the Basyx LIbrar should percent-encode the space to %20. |
I agree, perhaps we should already call |
Alright, I did some digging: When writing supplementary files, the basyx-python-sdk/basyx/aas/adapter/aasx.py Lines 555 to 559 in 0927305
For each supplementary file, it calls Normalization percent-encodes the string and converts it to lower case: Thus, it seems to me, that only the relationship files are expected to contain normalized, percent-encoded URIs, and the filenames are actually not expected to follow this format. If the filenames would be percent-encoded and converted to lower case, it would also be impossible to determine the original filename before packaging, and the assertion at the end of
Yet, So, I had a look at the specification you linked and it doesn't confirm my thoughts (well, partially):
Validating the filenames via |
Did I understand correctly, that this is a bug in the |
I think the
|
I was adding a file to an AASX which contained spaces. When writing the AASX, I got the following traceback:
Note that the error message is a bit misleading. It's not because of the
/
and not because of the.
. I double checked and it's the space that causes the problem.My expectation is that the Basyx library handles the file name at the level of
DictSupplementaryFileContainer
and theadd_file()
method. As written in the tutorial, the method shall return the actual file name. If spaces are not allowed, please return a file name without spaces.The text was updated successfully, but these errors were encountered: