Eclipse Community Forums: QVT-Relations » Problem with Parsing XML-Files

Home » Modeling » QVT-Relations » Problem with Parsing XML-Files(XML-Files with a certain Format aren't parsed correctly)

Problem with Parsing XML-Files [message #1803164]

Sun, 24 February 2019 08:09

Eclipse User

I use the default xmi-editor that comes with eclipse. The problem is the following:
whenever i edit the files in this editor, the references are saved in a certain format in text representation. This format concludes a reference by name like

<eClassifiers
xsi:type="ecore:EClass"
name="MyFirstClass">
<eStructuralFeatures
xsi:type="ecore:EReference"
name="multiRef"
eType="//MySecondClass"/> <-----------------
</eClassifiers>

<eClassifiers
xsi:type="ecore:EClass"
name="MySecondClass"/>

When i want to use qvtd however, i don't get any results nor errors, probably because qvtd won't work on this representation. At least until i change the representation in the text editor to

eType="//@eClassifiers.1"/> <-----------------

Since this is a pretty annoying process that i have to go through when i change anything in my xmi-models, i'd like to "skip" this step.
So is anyone else experiencing the same problems? Is qvtd not able to handle these references? Will it be in the future?
And concluding the question: am i able to change the default-representation for xmi-references by any chance, or will i have to parse and change them myself before using qvtd?

Thanks, i'm sure you guys can help me out there.

[Updated on: Sun, 24 February 2019 08:11] by Moderator

Re: Problem with Parsing XML-Files [message #1803171 is a reply to message #1803164]

Sun, 24 February 2019 11:36

Eclipse User

Hi

QVTd should work on any file that is readable by EMF, so what you write makes no sense.

Please post a repro project demonstrating the failure that you observe.

Regards

Ed Willink

Re: Problem with Parsing XML-Files [message #1803172 is a reply to message #1803171]

Sun, 24 February 2019 13:27

Eclipse User

Hi

What do you call the standard xmi-editor? To me, it is the Sample (Reflective) Ecore Editor, which is usually abbreviated to the Ecore editor, very rarely the XMI editor. Perhaps it is your not-so-standard editor that is the problem.

Regards

Ed Willink

Re: Problem with Parsing XML-Files [message #1803229 is a reply to message #1803172]

Mon, 25 February 2019 08:27

Eclipse User

Well, i'm using the "Sample Reflective Ecore Model Editor" to edit my models.
The "EMF Sample Ecore Editor" (which is the closest i could find to said editor in the beginning) is on version 2.16.v20181104-0733

I don't think that uploading a whole project makes any sense, since either way the problem seems to be in my Sample Reflective Ecore Model Editor.

So can you confirm that whenever you edit any models that contain references, that the text representation equals this format?

eType="//@eClassifiers.1"/>

May i ask on which version of eclipse it should be working on? I'm using the newest version of eclipse, maybe that's the issue?

Eclipse Modeling Tools
Version: 2018-12 (4.10.0)
Build id: 20181214-0600

My qvtd (so "QVT Declarative - All examples (Incubation)", "QVT Declarative All-In-One SDK (Incubation)" and "QVT Declarative Documentation (Incubation)") is on version 0.17.0.v20181211-0908

Also thanks already!

Re: Problem with Parsing XML-Files [message #1803241 is a reply to message #1803229]

Mon, 25 February 2019 11:21

Eclipse User

Hi

OK. 'XMI' Editor should not be the problem.

In my files I variously see #//name and //@... but not //name.

Unless you provide a file the fails to work with QVTd and a repro of how you use QVTd, I cannot investigate further. There are just too many magic inappropriate things that a user can do for me to guess at in trying to create a repro from your hints.

FWIW one of my test files maintained by the Ecore editor is as follows:

<?xml version="1.0" encoding="UTF-8"?>
<seq:Dummy xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:seq="http://www.eclipse.org/qvtd/xtext/qvtrelation/tests/seq2stm/SeqMM"
xsi:schemaLocation="http://www.eclipse.org/qvtd/xtext/qvtrelation/tests/seq2stm/SeqMM ../SeqMM.ecore">
<hasInteraction
name="interactions1">
<lifeline
name="lifeline"
state="//@containedState.0">
<msgEvent
prev="//@hasInteraction.0/@lifeline.0/@msgEvent.0"
next="//@hasInteraction.0/@lifeline.0/@msgEvent.0"
message="//@hasInteraction.0/@message.0"
state="//@containedState.0"/>
</lifeline>
<message
messageId="message1"
event="//@hasInteraction.0/@lifeline.0/@msgEvent.0"/>
</hasInteraction>
<containedState
name="state1"
messageevent="//@hasInteraction.0/@lifeline.0/@msgEvent.0"
lifeline="//@hasInteraction.0/@lifeline.0"/>
</seq:Dummy>

Perhaps you have a custom XXXResource that specifies a different xmi:id format and have neglected to alert QVTd to the variant Resource. But without a repro I can only guess wildly.

Regards

Ed Willink

Re: Problem with Parsing XML-Files [message #1803262 is a reply to message #1803241]

Mon, 25 February 2019 18:33

Eclipse User

ok, this is how i recreated the error also in earlier versions of Eclipse-Modeling:
- go to the Plugins-View
- import the org.eclipse.emf.ecore plugin as source project
- open the org.eclipse.emf.ecore/model/Ecore.ecore with the Sample Reflective Ecore Model Editor
- create a dynamic instance of the EPackage (and save the .xmi-file)
- create 2 Classes and a Reference between them (and of course give names to every element)
The text-representation should now match with my problem-format.

Additional to the "eType" Attribute, the "eOpposite" (also saved in references) isn't getting saved in the right format either.

I've also tried this on multiple versions of eclipse, including 2018-12, Indigo and Luna, so hopefully this will help to recreate a problematic xmi-file.

Re: Problem with Parsing XML-Files [message #1803272 is a reply to message #1803262]

Tue, 26 February 2019 00:55

Eclipse User

Hi

You could presumably provide me with the files that your procedure produces. This would save me time and avoid misunderstandings.

You could provide me with a QVTd transformation that fails. I might then know whether your problem was with QVTc or QVTr and how you were declaring your metamodels and attempting to use them. Without knowing how you do it, I will obviously have to assume that you do it my way and I will fail to reproduce your problem.

See https://wiki.eclipse.org/OCL/ForumNetiquette

Regards

Ed Willink

Re: Problem with Parsing XML-Files [message #1803306 is a reply to message #1803272]

Tue, 26 February 2019 10:29

Eclipse User

Hi Ed,

first of all thanks a great lot for your help and time!
I think I have to clarify some of Lukas statements...

We are currently working on 'migrating' (or rather reimplementing) our old medini-QVT (QVT-R) transformations to qvt-d but face some problems.

Lukas tries to write an Ecore to SQL transformation which behaves well in the case the source model (an Ecore model) is of the right format. I provide you a really small simplistic example that shows the problem at least on my system (Ubuntu 18.04, Eclipse Photon) and Lukas is facing similar problems (as mentioned above).

The simplified transformation (Ecore2SQL_simple.qvtr) should transform Ecore models into an SQL (SQL.ecore) representation. The very simple model My2.ecore (consisting of two lose classes) is transformed without any problems. The model with one containment reference between the two classes (My.ecore) is not transformed and there is no error stating why.

As Lukas tried to explain, he found out that changing in the Ecore files the notation of the applied occurences from ('#//') or ('//') to ('//@eClassifiers.' followed by the respective number) the transformation is executed correctly.

Thus, we are a little puzzled. It shouldn't mean we have to make this kind of string replacements? I just created the two models with the Ecore editor in the way I upload them (which seems to be the usual storage mechanism for applied occurences) and we don't see why the transformation is not creating target files without reporting errors. Maybe you can now reproduce the misbehavior and help us understanding what we might be doing wrong or what is going on at all?

If you need further details, just tell me... Thanks anyways for your efforts!

Attachment: Ecore2Sql2_simple.qvtr
(Size: 1.37KB, Downloaded 126 times)
Attachment: My.ecore
(Size: 0.58KB, Downloaded 120 times)
Attachment: My2.ecore
(Size: 0.43KB, Downloaded 150 times)
Attachment: SQL.ecore
(Size: 5.24KB, Downloaded 149 times)

Re: Problem with Parsing XML-Files [message #1803583 is a reply to message #1803272]

Mon, 04 March 2019 19:41

Eclipse User

Hi Ed,

I think I have to clarify some my statements, but first of all thanks a lot for your time and help on this issue!

What we are trying to do is to migrate or rather re-implement our old medini-QVT transformations in QVT-d. I am working on a transformation from Ecore to a relational database schema (SQL).

When we try to execute it, the success depends on the format of the input source file. As i tried to explain: if references to complex datatypes are not stored in a specific format, the transformation will not produce a trace and the target model but there is no error message. This is hard for us to work with.

I try to give you a short example for (hopefully) reproducing the misbehavior also on your system. I now also realized the same problems with Eclipse Photon on Ubuntu 18.04.

That's the literal contents of the Ecore class diagram, I created with the default Ecore Editor:

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="test" nsURI="http://de.ubt.ai1.mvmt.test.graph/test/" nsPrefix="de.ubt.ai1.mvmt.test.graph">
  <eClassifiers xsi:type="ecore:EClass" name="Graph">
    <eStructuralFeatures xsi:type="ecore:EReference" name="nodes" upperBound="-1"
        eType="#//Node" containment="true"/>
  </eClassifiers>
  <eClassifiers xsi:type="ecore:EClass" name="Node"/>
</ecore:EPackage>

With this source model as input, I don't get any resulting target model.
If we change the notation of the applied occurence of the Node class in the containment reference in the following way, we get a perfect result:

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="graph" nsURI="http://de.ubt.ai1.mvmt.test.graph/test/" nsPrefix="de.ubt.ai1.mvmt.test.graph">
  <eClassifiers xsi:type="ecore:EClass" name="Graph">
    <eStructuralFeatures xsi:type="ecore:EReference" name="nodes" upperBound="-1"
        eType="//@eClassifiers.1" containment="true"/>
  </eClassifiers>
  <eClassifiers xsi:type="ecore:EClass" name="Node"/>
</ecore:EPackage>

So we changed, the representation of the EReferences type from

eType="#//Node"

eType="//@eClassifiers.1"

. Maybe there is some issue with resolving the applied occurences?

The exact same thing is also happening with EReferences of type

eType="//Node"

, which happen to appear in the same places on some of our other test-systems (primarily under Windows with the version of Eclipse 2018-12).

The corresponding transformation:

import ecoreMM : 'Ecore.ecore'::ecore;
import sqlMM : 'SQL.ecore'::sql;

/**
 * Transform a hierarchical StateMachine into a flat StateMachine.
 */
transformation ecore2sql::Ecore2SQL(ecore:ecoreMM, sql:sqlMM) {
	
	-- Package
	
	top relation Package2Schema {
		domain ecore ecorePackage : EPackage {
			name = ePackageName: String{}
		};
		
		enforce domain sql sqlSchema : Schema {
			name = ePackageName
		};
	}
	
	-- Class
	top relation Class2Table {
		domain ecore ecoreClass : EClassifier {
			name = eClassName : String{},
			ePackage = ePackage : ecore::EPackage{}
		};
		
		enforce domain sql sqlTable : Table {
			name = eClassName,
			owningSchema = owningSchema : sql::Schema{}
		};
		
		when {
			Package2Schema(ePackage, owningSchema);
		}
	}	
}

Sorry for putting everything literally inside this post, but it seems the file upload did not work that my colleague made a few days ago.

We hope you can help us on this issue because it would be tidious to change all applied ocurences for each new input model.

Besides, do you think it could be a solution to programatically load the files and run the execution, including some kind of transformation for the model that runs before qvtd gets executed?

There are also some other questions that we have in mind, but they are rather up to a new thread ;)

I hope based on this information you can help us, if you need more please just let me know.

Regards
Lukas

PS:
i've now also created a github repository for this bug. It is reachable under https://github.com/LukasSchwarz00/Ecore2Sql. Further instructions on how to test out the bug and different reference-formats can be found in the readme. The repo was created and tested with Eclipse 2018-12.

Re: Problem with Parsing XML-Files [message #1803601 is a reply to message #1803583]

Tue, 05 March 2019 04:34

Eclipse User

Hi

I missed the link to the GitHub and so constructed a JUnit test using your files. Both forms of reference work fine for me. But perhaps my JUnit test harness is too 'helpful'.

I see a major hazard. You are using Ecore which is installed, but also using a private Ecore.ecore. You should import

import ecoreMM : 'http://www.eclipse.org/emf/2002/Ecore';

If you really want a private Ecore, call it something like MyEcore and ensure that all model file names, package paths and nsURIs change.

When looking at the GitHub I see that your Ecore files have a *.xmi extension which might account for an Ecore-variant of the references failing.

Your Readme provides some but not enough details to allow me to reproduce. I need the launch configuration that you can locate/save into your workspace using the "Common Tab". When I try to create a launch config from your Readme it's disastrous, but not surprising since it is generating a private copy of Ecore etc. You presumably did rather better.

Ah! I created a compiled launch, since I like to have something easier to debug. If I use an interpreted launch, I can reproduce your concern. The CG launch causes a user-EObject to inherit from an EMF-EObject which not surprisingly provokes some namespace bugs in EMF's JET templates.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=545042 raised. Add yourself to the CC list to see progress.

--

Quote:

What we are trying to do is to migrate or rather re-implement our old medini-QVT transformations in QVT-d. I am working on a transformation from Ecore to a relational database schema (SQL).

Wow. Some real users. I hope you appreciate that Eclipse QVTd is only 0.X and so only recommended to researchers. Progress is very slow since I am discovering that the language design was never completed.

If you can identify discrepancies between MedinQVT and Eclipse QVTd this may helpfully contribute to a migration guide / bug fixes / enhancement requests...

You make find that https://wiki.eclipse.org/OCL/ForumNetiquette providers some help in producing repros that enable me to respond faster to a problem.

Regards

Ed Willink

Re: Problem with Parsing XML-Files [message #1803618 is a reply to message #1803601]

Tue, 05 March 2019 10:02

Eclipse User

Hey Ed,

god, yes I really missed that point on the import but you are totally right! Now it's running on all files ;) Thanks for the remark!

So we can focus on the real implementation issues...

Do you already support queries in qvt-d and to what extent? What we actually need, are some OCL expressions for assigning certain values, like concatenated strings or queries for finding corresponding types in the target model.

And yes we have made the same observation that the language was never completely developed nor realized. Especially when realizing incremental and bidirectional transformations, it needs a lot of tricks to properly implement bidirectional behavior. If you are interested, Bernhard Westfechtel pointed out some of the issues in his most recent publications.

When we are done with the implmentation, I think Lukas can make a list of some migration points and post them as guide lines ;)

Best,
Sandra

Re: Problem with Parsing XML-Files [message #1803622 is a reply to message #1803618]

Tue, 05 March 2019 11:42

Eclipse User

Hi

AFAIAA queries are 100% working. However since the scheduler must perform a deep global analysis to discover the transitive dependencies, you can probably come up with an example that hits an assert.

There was/is some two year old incremental functionality but only exercised for a toy example. Almost certainly needs work to catch up with development of relation overrides and cyclic scheduling.

Bidirectional transformations is a completely separate issue. QVTr is interesting. It provides a framework in which the declarative bits can be bidirectional, yet the awkward bits can be independently and manually unidirectional. My test harness has one example that is run both ways. For QVTr, bidirectional involves two activities; synthesize a directionally neutral middle metamodel, project the multidirectional exposition towards a specific direction. Eclipse QVTr, can do both of these. Longer term incremental should allow the neutral middle model to be updated from whichever direction has a change; still to do.

(In the next couple of weeks I will be preparing an ICGT submission to re-introduce QVTc/r to the GT community now that the underlying tooling uses a very graphical QVTs.)

Regards

Ed Willink

Re: Problem with Parsing XML-Files [message #1803753 is a reply to message #1803618]

Fri, 08 March 2019 06:11

Eclipse User

Sandra Greiner wrote on Tue, 05 March 2019 10:02

If you are interested, Bernhard Westfechtel pointed out some of the issues in his most recent publications.

Unfortunately these are not freely available and my ResearchGate request for a full text has received no response.

Regards

Ed Willink

Previous Topic:	OCL-Constraints
Next Topic:	Problem with Setting a Property with cardinality 1..*

Goto Forum:

-=] Back to Top [=-

Current Time: Thu Mar 27 01:18:05 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter