Encountered AnObsoleteProperty in an mxm file |
Post Reply |
Author | ||
bram.bolder
Contributor Joined: 09.Dec.2021 Location: Germany Points: 15 |
Post Options
Thanks(0)
Posted: 09.Nov.2022 at 04:48 |
|
When cleaning up one of my languages (I restructured some things and I removed old stuff via "Type Manager" -> "Delete Unselected"), I can use the language without any problems. Everything is defined. However when I export a graph to an mxm file, there are a lot of XML tags named "AnObsoleteProperty". These I can not import anymore. What helped is by simply replacing "AnObsoleteProperty" by "Property" in the mxm file with a simple search-and-replace tool. Then I can import the file and use it without any problem. How can I get to a state where exporting does not generate unreadable XML tags anymore? I depend on the XML export and import feature for collaboration projects.
|
||
stevek
MetaCase Joined: 11.Mar.2008 Points: 641 |
Post Options
Thanks(0)
|
|
If an exported instance states its type as 'AnObsolete...', that means that the type has been deleted from the repository. MetaEdit+ works hard to ensure that you can't delete types that are still used in the metamodel, but in cases where the metamodel has changed, there may be instances of types that were earlier part of the metamodel, but subsequently removed. As the manual says:
The MetaEdit+ Type Manager window does its best to search for those instances too, and even if it finds none, it will warn the user before deletion:
Could you paste a little example of the XML for such a property? (Feel free to change the user-entered type names and property values.) Are there many such property types, or are these all instances of the same property type?
|
||
bram.bolder
Contributor Joined: 09.Dec.2021 Location: Germany Points: 15 |
Post Options
Thanks(0)
|
|
The objects 'ROSPackage' and 'ROSTopicDefinition' are however still valid objects inside one of the languages used. I can still see them in the language itself and the 'Object Tool'. What might be confusing is that the property and the type have the same name. I was not very creative there .
|
||
stevek
MetaCase Joined: 11.Mar.2008 Points: 641 |
Post Options
Thanks(0)
|
|
The duplicate user-visible type names (typeName="ROSTopicDefinition" or "ROSPackage") aren't a problem: MetaEdit+ uses direct references, not lookup based on names. That lets you change the user-visible names freely, use the same name for a property type as for the type of object it can hold, or even have two object or property types with the same name (e.g. if combining metamodels from multiple sources, there will often be more than one Property type called Name, perhaps with different regexp constraints). The internal names of types (e.g. type="Object_ROSPackage_Thebes_7167849537") are unique in a repository. Rather than editing the MXM file to rename those obsolete types to just "Property", you should look in the MXT file to see what the actual internal name is in the metamodel now. Or just remove the type="..." attribute from those cases entirely - in which case MetaEdit+ will fall back on looking up a property type based on the user-visible typeName. Either way will allow your MXM to be imported.
The next question would be that you still have instances of obsolete types in your source repository, so it would be best to clean up the source once and for all, rather than have to hack exported MXM files. Deleting the models (just the instances of the metamodel that you have created with graphical GOPRR models) and then importing the tweaked MXM from above would be the easiest way. The new instances will have new oids, but otherwise be identical - and now match the current metamodel. |
||
bram.bolder
Contributor Joined: 09.Dec.2021 Location: Germany Points: 15 |
Post Options
Thanks(0)
|
|
OK, it was a bit more than just removing the 'type="..."'. I also needed to replace the typeName element. It changed to "Definition", even though internally the actual type is ROSTopicDefinition ("Definition" is just the name of the property). Well whatever. What solved my problem was to create a simple new dummy graph that included all the definitions I needed. This I exported and could then in the original mxm replace the "type and typeName" fields by those I found in the dummy export. I then deleted all conflicting graphs and could finally import the fixed mxm. I can use the graphs and also export them without trouble. Thanks.
|
||
stevek
MetaCase Joined: 11.Mar.2008 Points: 641 |
Post Options
Thanks(0)
|
|
Yes, that's right: as I mentioned, you can change the user-visible name of a type freely. The longer internal name will stay the same, so the original name will stay frozen there. Exporting the existing current metamodel or a model created with it to XML is a good way to see what kind of XML you need, and in particular the internal type name, as I mentioned above.
In many ways I'd suggest that's as far as you need to read. But since this is an interesting question of language workbench design, I'll jot some thoughts down. As background, MetaEdit+ chooses to use a shared repository and objects, rather than pushing things around in files like XML as the majority of other tools do.
What makes your case more complicated than normal MetaEdit+ use is that you're using the graphical GOPRR modelling language. That aims to be capable but simpler than the full GOPRR. It's a great introduction to metamodelling, but as I mentioned in the training, I wouldn't recommend it for production metamodelling. The form-based tools give you more power, and are also better able to hide the complexity of how to make things actually work - in particular with metamodel evolution when instances exist. The problem with file-based approaches is syncing and merging between different people and computers; when the metamodel (the schema) can change, that becomes even harder. When the metamodel is also part of the data to move, harder still. And when the metamodel is actually generated from a model that is also part of the data, it's really quite tricky. That's the case in the graphical metamodelling language - it's just another completely normal MetaEdit+ modelling language, and its generator happens to output in the XML format of MetaEdit+ metamodels. (And yes, there's a model in graphical GOPRR that generates the graphical GOPRR metamodel - everybody loves bootstrapping! But I digress...) In the form-based tools, you don't need to know about details like internal names; in the XML files, they need to be present to cope with cases where the metamodeller has changed the user-visible name. And when you're generating the XML files, rather than just saving them from metamodels and models made with the native tools, things are harder still. Basically in designing the graphical metamodelling language you can either expose the internals, and leave updating them correctly to the (meta)modeller, who will then have to understand the internal workings of MetaEdit+, or then choose a way to hide them but still allow as much of the power as possible. In this case, the choice in designing the graphical modelling language is between having to type two names for each type (the freely-changeable user-visible name and the unique, persistent long internal name), or having just one name and giving up some of the ability to change the metamodel freely when there are instances in this repository and other repositories. Since our aim was to complement the existing native form-based tools with an even simpler format, the choice was easy. It's also fair to note that most other tools out there would simply die on the first level of allowing metamodel evolution: here you were able to have graphical metamodelling, metamodel evolution, existing instances, and even forcibly delete types that still had instances, and the tool worked fine - it's only when you wanted to export to XML and import to another repository that you hit problems. Our goal in MetaEdit+ is to make things just work, from the point of view of the modeller and metamodeller. The form-based metamodelling tools can do that in a wider range of cases than any other tool we are aware of. The graphical metamodelling language can go quite a long way, better than many tools, but it will never be as good as the native form-based tools. Our experience as metamodellers is also that the form-based representation scales better to the size of most industrial domain-specific modelling languages — let alone massive languages designed by committee, aiming at broader domains. I love graphical representations, but they're not the best for everything. Of course maybe the graphical GOPRR language's goal of simplicity is what's holding it back - in which case anyone can make their own graphical metamodelling language in MetaEdit+, to suit their needs. We and others have done that in some cases. I've even built one in the existing graphical metamodelling language, and had it generate generators, but that's enough meta-levels that even I think I should stop writing now! Edited by stevek - 11.Nov.2022 at 12:18 |
||
Post Reply | |
Tweet |
Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |