Validation error during deserialization

Hi,

Due to project maintenance & upgrade requirement, we are upgrading Fesapi from V0.16.0.0 to V2.10.1.0 (a huge version gap). In order to guarantee the compatibility, we are trying to use the new Fesapi (V2.10.1.0) to import a pre-saved epc file (exported by V0.16.0.0). But, there are quite many validation message as shown in the snapshot. Do we miss extra steps/setups before the deserializeInto function? Appreciate for any proposal and solution to figure out theses issues.

Hi,

I guess you don’t provide the prop kind resources folder when you build your DataObjectRepository : Fesapi: common::DataObjectRepository Class Reference

Example : fesapi/example/example.cpp at 08a5d07151c0cfa4b35c8f18991cb09ae527c80b · F2I-Consulting/fesapi · GitHub

A basic prop kind resources folder is delivered with FESAPI : fesapi/resources at master · F2I-Consulting/fesapi · GitHub

Be also aware that a v2.12.0.0 has been released and should be preferred over a V2.10.1.0

Hi, your proposal works well. It is quite impressive that most of the validation errors have been cleaned up after attach the resource folder for DataObjectRepotory.
The remaining two categories of validation errors need more work. Could you please comment out how we could proceed with them. Thanks very much.

The red warning is a historical one : at the release time of RESQML2.0.1, a lot of implementations exported obj_EpcExternalPartReference as a RESQML object although it is an EML object. FESAPI allows this error, fixes it internally, and treat it as a warning… If you would reexport this file with a quite recent version of FESAPI, you would no more see this warning.

The red errors are clearly errors :

  • even if old FESAPI versions did not even try to validate that.
  • even if these errors are only checked when the resource package is used with FESAPI

If you look at the official PropertyKindMapping.xml in the resource folder, you could find dimensionless and permeability rock and see that they are indeed “abstract” meaning that they are not allowed to be used directly. Abstract prop kinds are just dedicated to be super kinds and you are just supposed to use or create one of their non abstract specializations.

The error about “permeability rock” is a quite well known one… “rock permeability”, which is not abstract, must be used instead!!! I know this looks weird and, imho, it is but this is the standard.

The error about “dimensionless” is a harder one. The exporter did not give enough specialization for this property kind : it is not allowed per the standard. The exporter must give more specialization about a dimensionless property kind.

Hi, it is confirmed that the red warning is gone (blue warnings remain) if export with recent version of Fesapi. That works pretty well. I tested another scenario that is export with new version of Fesapi and import the epc file with old version (0.16.0.0) of Fesapi. In old verison, only EpcDocument is used for deserialize() without DataObjectRepository. There is no validation at all. Does it make sense? Where and how the resource folder is provided for EpcDocument?

Regarding the blue warnings, It takes time to verify with coding. I will keep updated with any progress.

Additionally, all of these validation warnings should be theoretically respected. If we ignore them, whether it will affect the whole feature / specification / standard?

It looks to be at EpcDocument creation time : fesapi/example/example.cpp at 457082ebe90a3321e59e1f079b3cce779343b03c · F2I-Consulting/fesapi · GitHub
This version is so old that I don’t remember if it works well or not and how…

As told in the warning, an unvalid property kinds makes its related properties to be partial meaning that you would just know their name and uuid but nothing else about…
So, yes, this particular warning message would affect the import of the properties of this particular unvalid property kind.