Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Loading DSML file as EMF model
Loading DSML file as EMF model [message #714294] Wed, 10 August 2011 08:43 Go to next message
John Smith is currently offline John SmithFriend
Messages: 137
Registered: July 2009
Senior Member
Hi,

I made an EMF metamodel from the DSML xsd (describing the xml structure
of LDAP request/response documents), however have some difficulties
loading a DSML file as EMF model:

(1) the DSML file's root element is a <batchResponse>. This is a global
element in the xsd schema. However EMF only knows the type,
BatchResponse. So if I capitalize the starting and closing tag of the
root element, I solve this problem. However is there generaly no
solution to read a DSML-Schema compliant DSML document into EMF without
this patch? I know that EMF produces a DocumentRoot class with a
"batchResponse" reference, however this not helps to read original DSML
files.

(2) The DsmlValue simple type is a union of the types xsd:string,
xsd:base64 and xsd:anyURI, the EMF code generator maps it to an
java.lang.Object. What are actual instance class types at runtime? I
think java.lang.String will be the normal case, but java.net.URI or
org.eclipse.emf.common.util.URI will ever be instantiated by the EMF XMI
reader? What if the reader encounters a base64 value, what instance
class type I have to be prepared for? I would like to have all values be
accessible as String (also for model transformation reasons), how to
tell EMF that it shall use only strings? Just putting the instance type
name to java.lang.String of the DsmlValue EMF datatype produces a
compile error in validateDsmlValue_MemberTypes, then trying to cast a
String (instead of Object) to byte[].

So with the fix of (1) I am able to display DSML files in the reflective
editor using the generated EMF code. However the editor cannot be used
to edit DsmlValue values, as it cannot handle the Object type
adequately. It will be even harding to handle this in the model
transformation language QVT. Any ideas how to handle this?
Re: Loading DSML file as EMF model [message #714392 is a reply to message #714294] Wed, 10 August 2011 13:16 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33142
Registered: July 2009
Senior Member
Comments below.

On 10/08/2011 1:43 AM, exquisitus wrote:
> Hi,
>
> I made an EMF metamodel from the DSML xsd (describing the xml
> structure of LDAP request/response documents), however have some
> difficulties loading a DSML file as EMF model:
>
> (1) the DSML file's root element is a <batchResponse>. This is a
> global element in the xsd schema. However EMF only knows the type,
> BatchResponse.
I doubt that.
> So if I capitalize the starting and closing tag of the root element, I
> solve this problem.
It sounds more likely that you're not using the generated resource
factory to create the resources you're using to load or save the XML.
Or like you're not using a document root to build the instance.

> However is there generaly no solution to read a DSML-Schema compliant
> DSML document into EMF without this patch? I know that EMF produces a
> DocumentRoot class with a "batchResponse" reference, however this not
> helps to read original DSML files.
Yes it does, if you use the right options while loading...
>
> (2) The DsmlValue simple type is a union of the types xsd:string,
> xsd:base64 and xsd:anyURI, the EMF code generator maps it to an
> java.lang.Object.
That's the only common base class they share, right...
> What are actual instance class types at runtime?
One of the three supported by the types in the union.
> I think java.lang.String will be the normal case, but java.net.URI or
> org.eclipse.emf.common.util.URI will ever be instantiated by the EMF
> XMI reader?
No, but base64 maps to byte[].
> What if the reader encounters a base64 value, what instance class type
> I have to be prepared for?
You could see what actually happens in the code rather than ask. The
debugger is incredibly helpful.
> I would like to have all values be accessible as String (also for
> model transformation reasons), how to tell EMF that it shall use only
> strings?
You can use ecore:instanceTypeName to force it to be a particular type.
> Just putting the instance type name to java.lang.String of the
> DsmlValue EMF datatype produces a compile error in
> validateDsmlValue_MemberTypes, then trying to cast a String (instead
> of Object) to byte[].
Hmmm. I've never tried it for a union of incompatible types. Of course
your union sounds completely useless because xsd:string (assuming it's
first the way you've shown it) consumes all possible values).
>
> So with the fix of (1) I am able to display DSML files in the
> reflective editor using the generated EMF code. However the editor
> cannot be used to edit DsmlValue values, as it cannot handle the
> Object type adequately.
Why not? It should be able to work with string representations just as
it does for all other data types (given the generated factory supports
conversion to and from a string).
> It will be even harding to handle this in the model transformation
> language QVT. Any ideas how to handle this?
I'm not sure why it's hard. In the worst case, edit the schema you use
to produce Ecore to make the thing a string; as I said, the union as you
shown it sounds useless even from a schema point of view.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Loading DSML file as EMF model [message #715280 is a reply to message #714392] Sat, 13 August 2011 03:26 Go to previous messageGo to next message
John Smith is currently offline John SmithFriend
Messages: 137
Registered: July 2009
Senior Member
>> (1) the DSML file's root element is a <batchResponse>. This is a
>> global element in the xsd schema. However EMF only knows the type,
>> BatchResponse.

> I doubt that.

Yes, doubt is justified for the generated static metamodel, but when
just using the reflective metamodel (the .ecore file), then I cannot use
"batchRepsonse" as root element, only "BatchResponse" works. Is this a
bug ? Or am I missing something.

So LDAP responses can be saved as .dsml files by e.g. the Softerra LDAP
Browser and the funny thing is that I can immediately now load it as EMF
model (this works only for the static metamodel). DSML is an XML Schema
which is also used for LDAP servers supporting SOAP communication. So a
further step would be to write a SOAP client for those servers, and
passing an EMF DSML element as input parameter and getting a EMF DSML
element as result. However JAXWS platforms like CXF cannot serialize EMF
elements, so EMF currently not supports to be used in this way, right?
How to tell CXF to use the EMF's integrated XMI serializer, or the XMI
parser to parse the SOAP method return? The parser would need to
integrate into CXF's SOAP parser, right?
Re: Loading DSML file as EMF model [message #715286 is a reply to message #715280] Sat, 13 August 2011 04:31 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33142
Registered: July 2009
Senior Member
Comments below.

On 12/08/2011 8:26 PM, exquisitus wrote:
>
>>> (1) the DSML file's root element is a <batchResponse>. This is a
>>> global element in the xsd schema. However EMF only knows the type,
>>> BatchResponse.
>
>> I doubt that.
>
> Yes, doubt is justified for the generated static metamodel, but when
> just using the reflective metamodel (the .ecore file), then I cannot
> use "batchRepsonse" as root element, only "BatchResponse" works. Is
> this a bug ? Or am I missing something.
It sounds more likely a case of not using the right options during
loading or saving. What resource factory is being used to create it?
>
> So LDAP responses can be saved as .dsml files by e.g. the Softerra
> LDAP Browser and the funny thing is that I can immediately now load it
> as EMF model (this works only for the static metamodel). DSML is an
> XML Schema which is also used for LDAP servers supporting SOAP
> communication. So a further step would be to write a SOAP client for
> those servers, and passing an EMF DSML element as input parameter and
> getting a EMF DSML element as result. However JAXWS platforms like CXF
> cannot serialize EMF elements, so EMF currently not supports to be
> used in this way, right? How to tell CXF to use the EMF's integrated
> XMI serializer, or the XMI parser to parse the SOAP method return? The
> parser would need to integrate into CXF's SOAP parser, right?


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Loading DSML file as EMF model [message #715926 is a reply to message #715286] Tue, 16 August 2011 02:12 Go to previous messageGo to next message
John Smith is currently offline John SmithFriend
Messages: 137
Registered: July 2009
Senior Member
>> Yes, doubt is justified for the generated static metamodel, but when
>> just using the reflective metamodel (the .ecore file), then I cannot
>> use "batchRepsonse" as root element, only "BatchResponse" works. Is
>> this a bug ? Or am I missing something.
> It sounds more likely a case of not using the right options during
> loading or saving. What resource factory is being used to create it?
Well the reflective metamodel I test in the develpor workbench, and
generate code of it. The generated metamodel I currently test in the
runtime workbench. The resource factory for the reflective metamodel is
some of Eclipse itself, not mine code, since of course the generated
code gets activated only in the runtime workbench

>>
>> So LDAP responses can be saved as .dsml files by e.g. the Softerra
>> LDAP Browser and the funny thing is that I can immediately now load it
>> as EMF model (this works only for the static metamodel). DSML is an
>> XML Schema which is also used for LDAP servers supporting SOAP
>> communication. So a further step would be to write a SOAP client for
>> those servers, and passing an EMF DSML element as input parameter and
>> getting a EMF DSML element as result. However JAXWS platforms like CXF
>> cannot serialize EMF elements, so EMF currently not supports to be
>> used in this way, right? How to tell CXF to use the EMF's integrated
>> XMI serializer, or the XMI parser to parse the SOAP method return? The
>> parser would need to integrate into CXF's SOAP parser, right?

Can you say some words about this issue? how to use the same
serialization which works for standalone files also for webservice
invocations?
Re: Loading DSML file as EMF model [message #716184 is a reply to message #715926] Tue, 16 August 2011 15:58 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33142
Registered: July 2009
Senior Member
Comments below.

On 15/08/2011 7:12 PM, exquisitus wrote:
>
>>> Yes, doubt is justified for the generated static metamodel, but when
>>> just using the reflective metamodel (the .ecore file), then I cannot
>>> use "batchRepsonse" as root element, only "BatchResponse" works. Is
>>> this a bug ? Or am I missing something.
>> It sounds more likely a case of not using the right options during
>> loading or saving. What resource factory is being used to create it?
> Well the reflective metamodel I test in the develpor workbench, and
> generate code of it.
Yes, the reflective editor uses XMI.
> The generated metamodel I currently test in the runtime workbench. The
> resource factory for the reflective metamodel is some of Eclipse
> itself, not mine code, since of course the generated code gets
> activated only in the runtime workbench
There should be a generated resource factory and it should be getting
used (assuming it doesn't use a file extension that conflicts with some
other registration). Try invoking Generate Test Code and looking at the
generated XyzExample.java. It should work properly no matter what else
is registered...
>
>>>
>>> So LDAP responses can be saved as .dsml files by e.g. the Softerra
>>> LDAP Browser and the funny thing is that I can immediately now load it
>>> as EMF model (this works only for the static metamodel). DSML is an
>>> XML Schema which is also used for LDAP servers supporting SOAP
>>> communication. So a further step would be to write a SOAP client for
>>> those servers, and passing an EMF DSML element as input parameter and
>>> getting a EMF DSML element as result. However JAXWS platforms like CXF
>>> cannot serialize EMF elements, so EMF currently not supports to be
>>> used in this way, right? How to tell CXF to use the EMF's integrated
>>> XMI serializer, or the XMI parser to parse the SOAP method return? The
>>> parser would need to integrate into CXF's SOAP parser, right?
>
> Can you say some words about this issue?
You're asking about CXF, which I know nothing about...
> how to use the same serialization which works for standalone files
> also for webservice invocations?
Generally what folks end up doing is implementing some type of wrapper
for the EObjects which determines the containing resource
(EObject.eResource()) and serializes that.


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:(Bug?) CDO + EMF Query
Next Topic:Re: Cannot resolve MinimalEObjectImpl$Container
Goto Forum:
  


Current Time: Fri Apr 26 15:43:57 GMT 2024

Powered by FUDForum. Page generated in 0.03138 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top