MetaCase Homepage
Forum Home Forum Home > > MetaEdit+
  New Posts New Posts RSS Feed - Encountered AnObsoleteProperty in an mxm file
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

Encountered AnObsoleteProperty in an mxm file

 Post Reply Post Reply
Author
Message
bram.bolder View Drop Down
Contributor
Contributor


Joined: 09.Dec.2021
Location: Germany
Points: 15
Post Options Post Options   Thanks (0) Thanks(0)   Quote bram.bolder Quote  Post ReplyReply Direct Link To This Post Topic: Encountered AnObsoleteProperty in an mxm file
    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.
Back to Top
stevek View Drop Down
MetaCase
MetaCase
Avatar

Joined: 11.Mar.2008
Points: 641
Post Options Post Options   Thanks (0) Thanks(0)   Quote stevek Quote  Post ReplyReply Direct Link To This Post Posted: 09.Nov.2022 at 08:39
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:
Quote All instance Graphs whose types are to be deleted will be removed, and explode or decompose links to those Graphs will be removed. Under normal circumstances, this will ensure that there are no instances left in the repository of types that are to be deleted. You are however responsible for making sure that no other instances of types to be deleted exist. This problem occurs most often with object types previously in a Graph type, but now removed: as no Graph type refers to that object type, it would be deleted, but it may still have instances in Graphs made when that object type was legal.

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:
Quote Currently there are no referenced instances loaded of the types to be deleted.
Unloaded instances may still exist and be used elsewhere in the repository.
Unless you are certain there are no references to such instances,
[or such references are ONLY through graphs whose types will be deleted]
you must cancel type 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?
Back to Top
bram.bolder View Drop Down
Contributor
Contributor


Joined: 09.Dec.2021
Location: Germany
Points: 15
Post Options Post Options   Thanks (0) Thanks(0)   Quote bram.bolder Quote  Post ReplyReply Direct Link To This Post Posted: 10.Nov.2022 at 00:40
<slot id="u2387065033" name="Definition">
  <property oid="_3_28622" type="AnObsoleteProperty_ROSTopicDefinition_Thebes_3127449836" typeName="ROSTopicDefinition"></property>
  <value>
    <object id="_3_27504" oid="_3_27504" type="Object_ROSTopicDefinition_Thebes_3127449836" typeName="ROSTopicDefinition">
      <slot id="u0574152135" name="Type">
        <property oid="_3_27506" type="Property_Type_Thebes_0574152135" typeName="Type"></property>
        <value>
          <string>AudioCommand</string>
        </value>
      </slot>
      <slot id="u5856498731" name="Package">
        <property oid="_3_27508" type="AnObsoleteProperty_ROSPackage_Thebes_7167849537" typeName="ROSPackage"></property>
        <value>
          <object id="_3_21128" oid="_3_21128" type="Object_ROSPackage_Thebes_7167849537" typeName="ROSPackage">
            <slot id="u8976905935" name="Label">
              <property oid="_3_21130" type="Property_Label_Thebes_8976905935" typeName="Label"></property>
              <value>
                <string>my_msgs</string>
              </value>
            </slot>
          </object>
        </value>
      </slot>
    </object>
  </value>
</slot>
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 .
Back to Top
stevek View Drop Down
MetaCase
MetaCase
Avatar

Joined: 11.Mar.2008
Points: 641
Post Options Post Options   Thanks (0) Thanks(0)   Quote stevek Quote  Post ReplyReply Direct Link To This Post Posted: 10.Nov.2022 at 22:49
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. 

The most likely scenario here is that you've created that property type twice, created instances of one or both, and then deleted one of the types that still had instances. Those instances of the obsolete type are thus still in the models, so you're seeing them when exporting. If you export the metamodel as MXT (and look at the MXT generated from the graphical GOPRR language), you presumably wouldn't see those obsolete types - the metamodel is now correct, but you're seeing instance data created at an earlier time. 

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.
Back to Top
bram.bolder View Drop Down
Contributor
Contributor


Joined: 09.Dec.2021
Location: Germany
Points: 15
Post Options Post Options   Thanks (0) Thanks(0)   Quote bram.bolder Quote  Post ReplyReply Direct Link To This Post Posted: 11.Nov.2022 at 03:09
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.
Back to Top
stevek View Drop Down
MetaCase
MetaCase
Avatar

Joined: 11.Mar.2008
Points: 641
Post Options Post Options   Thanks (0) Thanks(0)   Quote stevek Quote  Post ReplyReply Direct Link To This Post Posted: 11.Nov.2022 at 12:16
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
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 12.05
Copyright ©2001-2022 Web Wiz Ltd.

This page was generated in 0.031 seconds.