Open atextor opened 2 months ago
mjacoby
commented
2 months ago Thank you for your feedback and we will discuss this in our next developers meeting.
My personal opinion is that it would be bad practice to deliberately implement and accept invalid files just because they have not been properly validated before being published. The correct way forward would be to retract/fix/update these files to be actually compliant to the specification.
atextor
commented
2 months ago Thank you for the quick feedback. I fully agree, fixing the files would be the correct way. I just have the impression that this is not going to happen (due to the fact that the above mentioned issue #37 was closed without changes to the files in question), hence my proposal for the "next-best thing". If this is closed as "wontfix", it would be completely understandable, it's not AA4J's duty to work around this.
Rudra-sandeep
commented
1 month ago @atextor I have fixed the templates related to Zvei Digital Namplate and Zvei Technical Data you can find them in the below link Links: https://github.com/admin-shell-io/submodel-templates/tree/main/published/ZVEI_Digital_Nameplate/1/0 https://github.com/admin-shell-io/submodel-templates/tree/main/published/Technical_Data/1/1 Please try to load them again and if you still face the same issue then please add a comment here. The issue with the Asset Interfaces Description is forwarded to the respective WG
The IDTA repository submodel-templates contains the officially published SMTs. Several of these files are not readable with AAS4J due to deserialization failures. I'm aware that:
Nevertheless, the files do exist like that and the fix in AASXPE apparently only alleviates the problem in the future. All of the above issues have been closed, but the files are still not readable. I expect (and by that I mean: end users using software built using AAS4J expect) these files to be readable. If they contain invalid structures or values, the XmlDeserializer or details of its implementation should work around this, if necessary by handling certain files specially. Even if the files are invalid according to the specification, they are still officially issued by IDTA and incompatibilities between core AAS infrastructure components such as AAS4J and the official IDTA files are confusing for users and cast a poor light on Admin Shells as a whole.
IMHO, the only other valid option would be to have IDTA remove these broken files, but I don't think this is possible to the release/standardization process.
Here is a full list of .aasx files with marks whether they can be loaded (AAS4J 1.0.2):