Using java wrapper of FESAPI 2.0.0.0, i am creating epc resqml file, when i open it in epc validator v2.0.1 , i get following error message [Content_types].xml has problem in part name value.
This issue was not happening with fesapi version 1.3.0.0. How to fix it?
Hi @Husnain,
Could you ask more information the software company please? I would be curious about the reason.
@untereiner : maybe you can help ?
Hello Philippe,
Wanted to clarify on this topic.
We are using fesapi libraries to write Resqml 2.0.1 files.
We earlier used fesapi 1.2.0.0 to write Resqml 2.0.1 files.
We recently upgraded to fesapi 2.0.0.0 to write Resqml 2.0.1 files.
We are noticing that structurally they are different, though we can use corresponding version of fesapi libraries to read them back.
Please see the attached image showing the differences.
(1) Could you please comment about the difference in the epc files structures.
(2) Additionally, for the Resqml 2.0.1 file written with fesapi 2.0.0.0 the Resqml 2.0.1 file validator (from energistics site), initially displays a warning “[Content_Type].xml has problem in PartName value !”, though it proceeds to import and validate it successfully. We did not have this warning for the Resqml 2.0.1 file written with fesapi 1.2.0.0.
The Resqml validator warning mentioned above is only happening if we write Grid2dRepresentation bulkdata that will end up in .h5 file.
We use java wrapper of fesapi.
Thanks,
Shakir
Thanks @shakirhusain for this thorough comment.
The observed difference in the EPC files structure come from the new capability for FESAPI v2+ to handle multiples Energistics standard version in a same EPC document. Since we can have RESQML2.2 (coming) files and RESQML2.0.1 files in a same EPC document and since they can share the same UUID and the same content type, we need to separate those two objects in two different foldes within the EPC document. Hence, in FESAPI v2+, we now have a folder per Energistics standard version in the EPC document while in FESAPI v2-, we had all the XML files all together at the root of the EPC document.
I guess that the Geosiris validator did not take this possibility into account at the time of its development. And as far as I know, it is no more actively maintained. I asked @untereiner about some information and I will also ask someone else from Geosiris.
FYI, I can reproduce exactly what you are explaining with one of my unit testing file which I will use to explain to Geosiris.
@philippeVerney How can it be a good idea to put entities of the same uuid+type in the same EPC?
Given that in ETP, as was confirmed to me during WITSML meetings, considers dataspace+uuid as
the identity of objects/entities. That would make it impossible import such an EPC to an ETP space.
Even the type or optional version part of the ETP URI is not part of that identity.
Hi @ddevienne
I am (just) a bit surprised about the answer that has been given to you by WITSML (which does not rule the Energistics identifier specification which has never been finalized…) : dataspace+uuid. That’s more, to me, the quick, simple, pragmatic and generally practically true answer but this does not reflect the general case. This is not a bad answer but it does look to me it is a too quick one.
Good or bad, most of time and after long long discussions, the answer about the identity is generally tightly linked with how an ETP URI is built which is (where the version and the dataspace are optional)
The canonical form of a data object URI with a version is:
eml:///[dataspace(‘{path}’)/]{DataObjectType}(uuid={uuid},version=‘{version}’)
So, to me, all of those “attributes” define the identifier of an Energistics dataobject (the dataspace having a meaning only in ETP context) : dataspace, type, uuid, version
For example, it is allowed in an EPC document (or in an ETP store) to have:
- the same dataobject serialized in a RESQML2.0.1 and in a RESQML2.2 at the same time.It would for example allow some 2.0.1 readers not to be blocked when receiving such an EPC document while a 2.2 reader would be able to find more advanced information. You may claim that an ETP store would never do so and would serialize on the fly and it could definitely be true.
Here, only the datatype would change. - two different versions of the same Energistics dataobject for example myHorizon.version10 and myHorizon.version11.
Here only the version would change.
In these two latter cases, an EPC document would have some conflicts in file naming if the files are in the same folder (version support is still under construction in FESAPI)
In order to support those use cases and after discussion within the RESQML group, FESAPI v2+ put files in various folders.
Notice that FESAPI v2+ is (half) prepared for those use cases but do not force them at all. FESAPI does not do any judgement if it is a good idea or not to put entities of the same uuid+type in the same EPC. But FESAPI acknowledges that the standard technically allows those use cases.
@shakirhusain
I just received an answer from Jean-François Rainaud from Geosiris about the validator warning.
He has not got any validation issue with their latest validator called “RESQML web studio”, he acknowledges that there is no problem with the file I sent to him even if their previous validator raises an error message.
It does not look they plan to make any update to the validator as it is for now.
If there is an update it would be a major one shifting from this validator to their new tool “RESQML web studio”.
Jean François Rainaud can confirm you directly that if you want and, potentially, offer you an evaluation version of their “RESQML web studio”.
I can give you privately his email if you want if you not already have it. Here is his linkedin for information : Jean-Francois Rainaud - Geosiris | LinkedIn
I guess your perspective makes sense from a library and file backend only perspective.
But when you consider database backends, or what actual end-user applications supports in terms of functionality, using more than dataspace+uuid doesn’t work out too well.
It’s not called a uuid for nothing. Universally unique identifier.
The partitioning by dataspaces acknowledges the fact it can’t be that unique,
but allowing the same uuid for objects of the same space just because they have different types,
or worse, allowing two versions of the same objects, is just plain wrong IMHO.
Petrel droids are two uuids, one for a datasource, another for the object within that datasource.
Skua objects similarly have per-Project guids, which ends up equivalent (a Project has uuid too).
That’s why I specifically asked that question during a meeting, and the answer was categorical.
Philippe, thanks for the information and also following up about the validator.
Philippe,
Could you please send me email of Jean François Rainaud ?
Thanks,
Shakir