XMI not available; DAO.Field errors

[joergklausen]

https://github.com/ISO-TC211/HMMG/tree/master/XMI returns 404. If I want to use the HMMG in my own EA model, I need an XMI of the entire HMMG for import. Where can I find it, please?

[jetgeo]

That's correct. The XMI exports have been removed for now, as they have not been maintained. We will come back with an improved maintenance routine for reusable resources.

For using elements from the HM in your local project, you have several other options (https://github.com/ISO-TC211/HMMG/wiki#accessing-the-isotc-211-harmonized-uml-model):

• You can download a complete EA project from https://github.com/ISO-TC211/HMMG/tree/master/EA and export/copy the parts you need into your local project (https://github.com/ISO-TC211/HMMG/wiki#downloading-ea-project).
• You can import the parts you need as reusable assets from the cloud repository (https://github.com/ISO-TC211/HMMG/wiki#reusable-assets).

Hope this helps.

[joergklausen]

Thank you @jetgeo for this useful hint. I have now connected successfully to the reusable assets. However, when I try to import the 19156 model, I get a large number of DAO data type conversion errors. I can acknowledge them and proceed, but they are a nuisance at best, and maybe point to a real problem at worst.
These errors didn't show up with the complete model.
Any ideas where these might come from? I am using EA 15.1.

[jetgeo]

I don't know why you get these errors. Works fine in my projects... It may be some underlying hidden dependencies. Could you send a screenshot of one of the messages?
Did you import "package" or "package and dependencies"?

[sptws001]

Hi all,
I am running 15.1.1528 and tested both .eapx file with JET 4.0 enabled as well as .eap file without JET 4.0. I did not receive any errors.

I imported 19156 with dependencies as reusable assets, not the full model.

Could you confirm at which point you started seeing errors.

Tobias

[jetgeo]

FYI: I have exported and uploaded a complete set of updated XMI files (e6ed462). However, connecting to Reusable Assets is the safest way of accessing updated versions.

[sptws001]

Agreed. However, the non-standard port is a problem as our corporate firewalls block port 804. As discussed Knut, we need to come back to the 'published' versus 'editorial' versions of the EA project and XMI exports, and provide some clear guidance on how it is recommended that users work with these assets. The safest approach would be to make the Reusable Assets path as accessible as possible, then seriously consider which exports/snapshots of the EA project and XMI files we really want to have available as standalone downloadable resources. You have already identified model management as a topic for discussion, along with clarifying what we can and cannot change. Anything we can change should be incorporated into the core EA project as reusable assets. Anything we cannot change needs to be queued in such a sway that these proposals can be provided to the individual standards projects when they activated in order to have proposals reviewed and approved/denied as part of regular standard maintenance. The question I have not fully resolved in my own mind is how best to managed the backlog of proposals do they are easy assemble (e.g. do we simply have the core model with a set of XMI that we can selectively merge as required, do we want an editorial version of the EA model as reusable assets with proposals incorporated, etc.). Tobias

…

On Wed., May 20, 2020, 9:59 a.m. Knut Jetlund, ***@***.***> wrote: FYI: I have exported and uploaded a complete set of updated XMI files ( e6ed462 <e6ed462>). However, connecting to Reusable Assets is the safest way of accessing updated versions. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIUGBKUKJVELY2QPBCCKYXLRSPH2LANCNFSM4NE25ZNA> .

[joergklausen]

Hi all,
I am running 15.1.1528 and tested both .eapx file with JET 4.0 enabled as well as .eap file without JET 4.0. I did not receive any errors.

I imported 19156 with dependencies as reusable assets, not the full model.

Could you confirm at which point you started seeing errors.

Tobias

I started with a fresh empty .eapx file. The DAO.Field [0x00000d5d] errors showed up during the import of Package and Dependants of ISO19156, ISO19115, ISO19157 and possibly others that I didn't test. I have MS Access 2016 installed on this machine in case that has any bearing. During the import of ISO19115, there was also another message: Dependent package(s) with GUID(s) {B5536B70-181A-4f2e-9543-A4A8FE248CD5} do not exist in Registry.
I discovered that I had reported this problem with earlier versions of EA and the SVN repo at the time (#17 )

[sptws001]

Hi Jörg,
Thanks for the updates. I'll tried each of the noted standards to see if I can replicate the issue.

For curiosity, are you running 32bit or 64bit Access? I don't believe Access itself is the issue (it looks like I have 2016 64bit installed at this point), but rather there is an orphan somewhere.
My test results:

• I was able to import 19156 and 19157 without issue.
• I was able to import 19115-1 Amd 2.
• 19115 raised the exception related to the broken dependency with GUID {B5536B70-181A-4f2e-9543-A4A8FE248CD5}, and I saw an error quickly raised in relation to addition of a note link (to a diagram). I need to look into this some more as I am certain I had recently imported 19115 into a new project.

I will discuss with Knut and try to track down the object with the problematic GUID.

We'll keep you posted.

Regards,

Tobias

[joergklausen]

Hi Tobias
I have MS Access 2016 32bit.
Thanks for caring, kind regards
Jörg

[jetgeo]

GUID {B5536B70-181A-4f2e-9543-A4A8FE248CD5} is the subpackage "DGGS Equal Area Earth Reference System " in ISO 19170-1, which has a dependency on ISO 19115. The RAS generator considers dependencies both ways. However, the dependency should not have been in the RAS Registry for 19115. I have removed all dependent packages from each RAS Registry in order to enable individual imports, but I must have missed this one. I am generating a new version of the 19115 RAS Registry now, which unfortunately takes a while. It should work better with the new version (tomorrow European time).
Did you import with the choice "package" or "package and dependencies"? You should not get the error with the first alternative.

[sptws001]

Hi Knut! Thanks for jumping in :)

We're doing package + dependencies and the import without dependencies did not raise the missing GUID error. I also just tested with EA 14 v1429 and I noticed that it does not raise the missing GUID error, but if you watch the import dialog closely, the notelink error quickly flashes by.

Just drop a line when the update is complete and we can re-run our RAS tests.

Tobias

[jetgeo]

Ok. I recommend to use import without dependencies, and rather import manually the packages you need. The relations are maintained anyway and become available when the related package is imported. There are a lot of dependencies in the HM. If you import with dependencies, you will keep importing the same packages from different RAS registries.
The new version of the 19115 RAS Registry is available now. Hope the error is gone as well ;).

[joergklausen]

Good day all
I tried again scratch (EA 15.1.1528), importing ISO19156 and ISO 19115 from reusable assets without dependencies. With an .eapx file, the DAO.Field error 3421 (data type conversion error) pops many times. With an .feap file, the import runs through smoothly. I understand .eapx uses JET4.0, so I am assuming the problem is related to the MS Access installation somehow.

[sptws001]

Thanks Knut,
I will need to poke around the wiki as I thought I read somewhere that package + dependencies was the recommendation. This is also what one would do if uncertain of the surrounding connections. I agree that the relations are maintained anyway, that would negate some need for importing dependencies.

I tested the package-only import and the GUID error is gone. In the last half of the import, the import dialogue flashes a number error messages, but I cannot find any documentation online as to whether these are real errors or warnings from not importing all dependencies.

Thanks!
Tobias

[sptws001]

Hi Jörg, Installing the 32bit Access Runtime (downloadable for free from Microsoft) version 2010 or later may help, but I have never received DAO errors with EA before, so there is definitely an issue. I believe feap uses FireBird under the hood, which is why you are not seeing the errors. Tobias

…

On Thu, May 28, 2020 at 6:59 AM Jörg Klausen ***@***.***> wrote: Good day all I tried again scratch (EA 15.1.1528), importing ISO19156 and ISO 19115 from reusable assets. With an .eapx file, the DAO.Field error 3421 (data type conversion error) pops many times. With an .feap file, the import runs through smoothly. I understand .eapx uses JET4.0, so I am assuming the problem is related to the MS Access installation somehow. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIUGBKUD236YXUAZ3DQBIIDRTYYZBANCNFSM4NE25ZNA> .

-- Tobias Spears

[joergklausen]

These DAO.Field errors don't seem to have any effect on the GML schema that is the product I really need. From my point of view, the issue can be closed - thanks for your considerations.

[sptws001]

Sounds good Jörg - thanks!

[sptws001]

This issue has been closed following corrections made to resolve the missing GUID, coupled with the recommendation to import needed reusable assets individually rather than importing with dependencies.