Do we need checker rules?

[AsamDiegoSanchez]

Describe the problem/question

Do we need checker rules that can be implemented later to be used i.e in the Quality Checker Framework?
(see in OpenDRIVE (https://publications.pages.asam.net/standards/ASAM_OpenDRIVE/ASAM_OpenDRIVE_Specification/latest/specification/16_annexes/map_rules.html) and OpenSCENARIO XML)

Describe your research

The ASAM Quality Checker Framework (https://github.com/asam-ev/qc-framework) operates through a series of specialized "checkers," organized into checker libraries. These checkers evaluate different aspects of your files, ensuring they meet the required quality standards.

[ClemensLinnhoff]

I would definitely put that on the scope for the next OpenMATERIAL 3D project.

[ClemensLinnhoff]

We discussed this again and it might make sense to define a couple of basic rules already, so we can set up the documentation and everything we need. This will make it easier to extend the set of rules in the future.

[ClemensLinnhoff]

Rules have an ID in the following format:
<emanating-entity>:<standard>:x.y.z:rule_set.for_rules.rule_name.

The emanating-entity is asam.net.
As a short string for the standard OpenSCENARIO XML for example uses xosc. This is also the file extension of OpenSCNEARIO XML files. It makes sense, since OpenSCENARIO XML only has one file format. We have multiple file formats. But I don't think it makes sense to have a different standard tag for each file format. However, it might make sense to differentiate between the two parts we have defined: Geometry and Material. But we might also have rules that are applicable to both. So how about the following standard strings:

• xom: General rules applicable for both parts
• xom-g: For OpenMATERIAL 3D: Geometry
• xom-m: For OpenMATERIAL 3D: Material (Here my only concern is, that people might confuse this string with the xomm file format for our mapping files).

Another possibility would be to use the rule-set string as a differentiation between general, geometry and material. On the other had, we might want to use it to group rules within the sub-parts.

[ClemensLinnhoff]

Proposed rules

General

asam.net:xom:1.0.0:general.valid-json-document: ASAM OpenMATERIAL 3D files with the file extensions .xoma, .xomm, .xomp or .xompt shall be valid json documents.

asam.net:xom:1.0.0:general.valid-schema: ASAM OpenMATERIAL 3D files with the file extensions .xoma, .xomm, .xomp or .xompt shall be valid according to their corresponding json schema.

asam.net:xom:1.0.0:general.uris_exist: If an URI property to other file is set in a json file, the file linked in that property shall exist.

Geometry

asam.net:xom-geo:1.0.0:asset.vehicleClassData-defined: If an asset is of type 'vehicle', the property 'vehicleClassData' must be set in the metadata.

asam.net:xom-geo:1.0.0:asset.humanClassData-defined: If an asset is of type 'human', the property 'humanClassData' must be set in the metadata.

I propose to leave out any rules related to the inside of 3D model files for now, because checking them in the checker bundle would require loading these files. Because of the multiple supported file formats (glTF, FBX, USD) this is a bit more implementation work. It would make sense to give this kind of implementation to a suitable service provider in the next OpenMATERIAL 3D project.

[ClemensLinnhoff]

I think we have not defined this in the documentation, yet. But should all meshes either have an OpenMATERIAL assignment texture or be covered in the mapping table by name? In other words: do we require an asset to be fully defined by OpenMATERIAl materials? Or can there be meshes without an OpenMATERIAL assigned to it?

In any case, this rule most likely requires to load the 3D model, so I would not implement it in this project, but we can already specify it in the documentation at least.

[ClemensLinnhoff]

Decision about rule IDs:

• xom: General rules applicable for both parts or not categorizable because they are in-between
• xom-geo: For OpenMATERIAL 3D: Geometry
• xom-mat: For OpenMATERIAL 3D: Material