Home » Modeling » EMF » using ecore save and load
| using ecore save and load [message #394003] |
Tue, 28 June 2005 09:57  |
Eclipse User |
|
|
|
Originally posted by: arti_subscribe.rediffmail.com
Hi,
I am trying to use ecore's xmi save and xmi load implementation api's.
I have my own implementation of storing and fetching models (implemented
MOF interfaces). The export(save) and import(load) have been more or less
succesful barring a few problems. They are as follows:-
___________
export
___________
1) According to XMI specifications, same document references are
represented as "#someid" whereas cross doc references are represented as
"anotherfile#someid"
However when I export my model , none of the references (which were
instances of EReference) were preceded by a '#'.
e.g.
target=" myid:6b0691a68889a07aaa160544b8ee8cf079f6270a898e03ccd006fcd b "
should have actually got serialized as
target=" #myid:6b0691a68889a07aaa160544b8e8cf079f6270a898e03ccd006fcd b "
___________
import
___________
1) While importing, I have manually added the '#' to all references so
that they are considered for forwardreference resolution. In ecore's
XMLHandlerImpl, there is a method handleforwardreferences which gets
invoked when endDocument is true. However, the code for this method does
not resolve the references (ideally it should have invoked
EObjectImpl.eSet, but it does not, it just adds all the resolved objects
to a list (InternalElist) ).
I have confirmed that the referenced objects have been created, so their
existance is not an issue.
Can anyone please give any pointers on these. Thanks a lot for your time.
Arti
|
|
|
| Re: using ecore save and load [message #394015 is a reply to message #394003] |
Tue, 28 June 2005 11:55  |
| Eclipse User |
|
|
|
Arti,
A same document reference will often (typically) be serialized as an
IDREF instead of as an anyURI. It's possible to override XMLSaveImpl's
sameDocSingle and sameDocMany to always return CROSS_DOC.
Proxies should typically not be resolved during loading, since that can
cause additonal loads of other documents, and those might need to refer
back to the document currently being loaded. The proxies should be
resolved on demand. Only same document references should be resolved
during a load, and adding them to sameDocumentProxies should cause that
to happen.
Arti wrote:
> Hi,
>
> I am trying to use ecore's xmi save and xmi load implementation api's.
> I have my own implementation of storing and fetching models
> (implemented MOF interfaces). The export(save) and import(load) have
> been more or less succesful barring a few problems. They are as follows:-
> ___________
> export
> ___________
> 1) According to XMI specifications, same document references are
> represented as "#someid" whereas cross doc references are represented
> as "anotherfile#someid"
> However when I export my model , none of the references (which were
> instances of EReference) were preceded by a '#'.
> e.g.
> target=" myid:6b0691a68889a07aaa160544b8ee8cf079f6270a898e03ccd006fcd b "
> should have actually got serialized as
> target=" #myid:6b0691a68889a07aaa160544b8e8cf079f6270a898e03ccd006fcd b "
> ___________
> import
> ___________ 1) While importing, I have manually added the '#' to all
> references so that they are considered for forwardreference
> resolution. In ecore's XMLHandlerImpl, there is a method
> handleforwardreferences which gets invoked when endDocument is true.
> However, the code for this method does not resolve the references
> (ideally it should have invoked EObjectImpl.eSet, but it does not, it
> just adds all the resolved objects to a list (InternalElist) ). I have
> confirmed that the referenced objects have been created, so their
> existance is not an issue.
>
> Can anyone please give any pointers on these. Thanks a lot for your time.
>
> Arti
>
|
|
|
| Re: using ecore save and load [message #394037 is a reply to message #394015] |
Wed, 29 June 2005 10:22 |
| Eclipse User |
|
|
|
Originally posted by: arti_subscribe.rediffmail.com
Hi Ed,
Thanks a lot for your reply.
I'm still not clear about a few issues. Would like to rephrase the problem.
Our assumptions
===============
1) EMF Ecore interfaces can be implemented by any users. Users can have
their own representation of models. In memory , database or anything else.
2)EMF XMI Save , Load can be used to Store and Load models for all EMF
compliant tools (any users who implement EMF Ecore interfaces)
With these two assumptions, we started implementing only EMF interfaces,
to get XMI export,import facilities for our repositories (MOF compliant).
We have database storage for our models and its not in-memory as per
default EMF's implementation.
Please confirm whether these assumptions and our approach in using EMF is
correct.
While doing this we faced following problems:
1) we could not understand EMF's requirements for id attribute values. We
have id values as packageurl.TypeName:uniqueNumber
e.g.
com.ttt.aaaa.MetaMetaModel.Class:983f3b6d51ba099189112ed59d4 06464f8a48f941616609c1109736c86b453a1
Same is exported in xml document. Here is a snapshot from the exported xml
document. (Note: EXTERNALID is defined as our id attribute)
<?xml version="1.0" encoding="ASCII"?>
<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:com.ttt.aaaa.MetaMetaModel="com.ttt.aaaa.MetaMetaModel ">
<com.ttt.aaaa.MetaMetaModel:Package Name="Package Extension Top Package"
URL="com.ttt.aaaa.toppkg" dependsOnType="com.ttt.aaaa.MetaMetaModel">
<contains xmi:type="com.ttt.aaaa.MetaMetaModel:Package"
Name="MetaMetaModel" URL="com.ttt.aaaa.MetaMetaModel"
dependsOnType="com.ttt.aaaa.MetaMetaModel"
dependentInstance="com.ttt.aaaa.toppkg com.ttt.aaaa.MetaMetaModel">
<contains xmi:type="com.ttt.aaaa.MetaMetaModel:Class" Name="Object"
EXTERNALID=" com.ttt.aaaa.MetaMetaModel.Class:183d4c72d1645f732a066c827d1 06ddae90d378eafa33a21b8e7b009aaaaf990 "
isAbstract="Y"
inheritedBy=" com.ttt.aaaa.MetaMetaModel.Class:983f3b6d51ba099189112ed59d4 06464f8a48f941616609c1109736c86b453a1 "
targetOf=" com.ttt.aaaa.MetaMetaModel.Association:c103e4a934041dc15d953 3d2c3d963bbedba36bc7745f8ee982604ffc37141e9 "/>
:
:
<contains xmi:type="com.ttt.aaaa.MetaMetaModel:Association"
Name="Package_contains_Object"
EXTERNALID=" com.ttt.aaaa.MetaMetaModel.Association:c103e4a934041dc15d953 3d2c3d963bbedba36bc7745f8ee982604ffc37141e9 "
tgtNavigable="Y" srcNavigable="Y" tgtCard="0..m" srcCard="0..1"
invName="container" fwdName="contains"
source=" com.ttt.aaaa.MetaMetaModel.Class:6fd4bbaa7a7cf46d8f578c382b3 a05bc5eb14bf710bc5dfdb5c2ccfa42a28cdb "
target=" com.ttt.aaaa.MetaMetaModel.Class:183d4c72d1645f732a066c827d1 06ddae90d378eafa33a21b8e7b009aaaaf990 "/>
:
:
</com.ttt.aaaa.MetaMetaModel:Package>
</xmi:XMI>
But with this EMF XMI import does not work. It fails in reference
resolution , even though referenced objects are present in the same
document.All our references are 'SAME DOC' types. We currently don't have
any 'CROSS DOC' references.
Is it required that the keyword 'idref' be present in the references. If
yes, what makes export print this keyword.
Is it also required that the references get added to the
sameDocumentProxies list, so that they are resolved. If yes, then in what
way should export serialize this so that it gets added to this list.
2)We assumed that XMI save and load should be working with only EMF Ecore
interfaces. But it looks like at some places it assumes in memory
representation of model.
e.g
In XMLHelperImpl
public void setValue(EObject object, EStructuralFeature feature, Object
value, int position)
{
:
:
case IS_MANY_MOVE:
{
InternalEList list = (InternalEList) object.eGet(feature);
if (position == -1)
{
list.addUnique(value);
}
else if (position == -2)
{
list.clear();
}
else if (kind == IS_MANY_ADD)
{
list.addUnique(position, value);
}
else
{
list.move(position, value);
}
break;
:
:
}
In order to make it working we need to extend this method.
Is it expected that users should extend XMI Helper and XMI Handler
implementation ?
Thanks
Arti
|
|
|
| Re: using ecore save and load [message #394042 is a reply to message #394037] |
Wed, 29 June 2005 18:10 |
| Eclipse User |
|
|
|
Atri,
You can implement EObject directly, but it's assumed that all
implementations also implement InternalEObject. It's also assumed that
all isMany features return a List that implements InternalEList. It's
really best to extend the BasicEObjectImpl, which doesn't allocate any
storage, leaving that to the extender. There is also the
EStoreEObjectImpl which delegates all data access to an
InternalEObject.EStore, which can then query a database or whatever;
unfortunately we don't have good examples to show how to use it. I can
explain more if this is of interest. (Or you can search previous
descriptions in the newsgroup history using the instructions on the
documentation page.)
Is your EXTERNALID an EAttribute with isID set to true? That's
necessary if you want to be able to reference that as an ID. Same
document proxies should be handled automatically without effort on your
part. Yes, extending the helpers/handlers is reasonable for doing
specialized things. Lots of people do.
Arti wrote:
> Hi Ed,
>
> Thanks a lot for your reply.
> I'm still not clear about a few issues. Would like to rephrase the
> problem.
>
> Our assumptions ===============
> 1) EMF Ecore interfaces can be implemented by any users. Users can
> have their own representation of models. In memory , database or
> anything else.
> 2)EMF XMI Save , Load can be used to Store and Load models for all
> EMF compliant tools (any users who implement EMF Ecore interfaces)
>
> With these two assumptions, we started implementing only EMF
> interfaces, to get XMI export,import facilities for our repositories
> (MOF compliant). We have database storage for our models and its not
> in-memory as per default EMF's implementation.
>
>
> Please confirm whether these assumptions and our approach in using EMF
> is correct.
>
> While doing this we faced following problems:
>
> 1) we could not understand EMF's requirements for id attribute
> values. We have id values as packageurl.TypeName:uniqueNumber
> e.g.
> com.ttt.aaaa.MetaMetaModel.Class:983f3b6d51ba099189112ed59d4 06464f8a48f941616609c1109736c86b453a1
>
>
> Same is exported in xml document. Here is a snapshot from the exported
> xml document. (Note: EXTERNALID is defined as our id attribute)
>
> <?xml version="1.0" encoding="ASCII"?>
> <xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
> xmlns:com.ttt.aaaa.MetaMetaModel="com.ttt.aaaa.MetaMetaModel ">
> <com.ttt.aaaa.MetaMetaModel:Package Name="Package Extension Top
> Package" URL="com.ttt.aaaa.toppkg"
> dependsOnType="com.ttt.aaaa.MetaMetaModel">
> <contains xmi:type="com.ttt.aaaa.MetaMetaModel:Package"
> Name="MetaMetaModel" URL="com.ttt.aaaa.MetaMetaModel"
> dependsOnType="com.ttt.aaaa.MetaMetaModel"
> dependentInstance="com.ttt.aaaa.toppkg com.ttt.aaaa.MetaMetaModel">
> <contains xmi:type="com.ttt.aaaa.MetaMetaModel:Class"
> Name="Object"
> EXTERNALID=" com.ttt.aaaa.MetaMetaModel.Class:183d4c72d1645f732a066c827d1 06ddae90d378eafa33a21b8e7b009aaaaf990 "
> isAbstract="Y"
> inheritedBy=" com.ttt.aaaa.MetaMetaModel.Class:983f3b6d51ba099189112ed59d4 06464f8a48f941616609c1109736c86b453a1 "
> targetOf=" com.ttt.aaaa.MetaMetaModel.Association:c103e4a934041dc15d953 3d2c3d963bbedba36bc7745f8ee982604ffc37141e9 "/>
>
> :
> :
> <contains xmi:type="com.ttt.aaaa.MetaMetaModel:Association"
> Name="Package_contains_Object"
> EXTERNALID=" com.ttt.aaaa.MetaMetaModel.Association:c103e4a934041dc15d953 3d2c3d963bbedba36bc7745f8ee982604ffc37141e9 "
> tgtNavigable="Y" srcNavigable="Y" tgtCard="0..m" srcCard="0..1"
> invName="container" fwdName="contains"
> source=" com.ttt.aaaa.MetaMetaModel.Class:6fd4bbaa7a7cf46d8f578c382b3 a05bc5eb14bf710bc5dfdb5c2ccfa42a28cdb "
> target=" com.ttt.aaaa.MetaMetaModel.Class:183d4c72d1645f732a066c827d1 06ddae90d378eafa33a21b8e7b009aaaaf990 "/>
>
> :
> :
> </com.ttt.aaaa.MetaMetaModel:Package>
> </xmi:XMI>
>
>
> But with this EMF XMI import does not work. It fails in reference
> resolution , even though referenced objects are present in the same
> document.All our references are 'SAME DOC' types. We currently don't
> have any 'CROSS DOC' references.
> Is it required that the keyword 'idref' be present in the references.
> If yes, what makes export print this keyword.
> Is it also required that the references get added to the
> sameDocumentProxies list, so that they are resolved. If yes, then in
> what way should export serialize this so that it gets added to this list.
>
> 2)We assumed that XMI save and load should be working with only EMF
> Ecore interfaces. But it looks like at some places it assumes in
> memory representation of model.
> e.g
> In XMLHelperImpl
> public void setValue(EObject object, EStructuralFeature feature,
> Object value, int position)
> {
> :
> :
>
> case IS_MANY_MOVE:
> {
> InternalEList list = (InternalEList) object.eGet(feature);
>
> if (position == -1)
> {
> list.addUnique(value);
> }
> else if (position == -2)
> {
> list.clear();
> }
> else if (kind == IS_MANY_ADD)
> {
> list.addUnique(position, value);
> }
> else
> {
> list.move(position, value);
> }
> break;
> :
> :
> }
>
> In order to make it working we need to extend this method.
> Is it expected that users should extend XMI Helper and XMI Handler
> implementation ?
>
> Thanks
> Arti
>
>
|
|
|
| Re: using ecore save and load [message #394058 is a reply to message #394042] |
Thu, 30 June 2005 10:03 |
| Eclipse User |
|
|
|
Originally posted by: arti_subscribe.rediffmail.com
Thanks Ed,
--We have already implemented all ecore interfaces
(EObject,InternalEObject,EReference etc..) Also, our EXTERNALID is an
EAttribute with its isId set to true.
--You have said that same document proxies should be handled by itself.
But, it looks like we have to extend some methods of ecore's XMLHelperImpl
to handle this.
We have observed that somehow the setValueFromId method of the XMLHandler
requires that there be a '#' in the representation of references,otherwise
it invokes helper's setValue with a 'null' in place of the referenced
object's id. To get that '#' we have extended helper's getIDRef method.
Would like to know if there is any documentation available, that mentions
which of ecore's implementations can/should be extended by the users.
--We are also facing some trouble with the namespaces and top element
container.
1)while exporting , how is the namespace for a package decided
2)while importing,where does the top element get created ?
e.g. we have a package 'X' that contains package 'Y'. The package 'Y'
contains many other packages,objects etc. Now, when we export only package
'Y', we define the resource as this package. If we import this document,
where should package 'Y' be created.What should be defined as the
resource.
Thanks for all your time and effort.
Arti
|
|
|
| Re: using ecore save and load [message #394060 is a reply to message #394058] |
Thu, 30 June 2005 11:25 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------090301040004040500050301
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Arti,
The handling of #<ID> and <ID> should be the same:
protected void setValueFromId(EObject object, EReference
eReference, String ids)
{
StringTokenizer st = new StringTokenizer(ids);
boolean isFirstID = true;
boolean mustAdd = deferIDREFResolution;
boolean mustAddOrNotOppositeIsMany = false;
int size = 0;
String qName = null;
int position = 0;
while (st.hasMoreTokens())
{
String id = st.nextToken();
int index = id.indexOf("#");
if (index != -1)
{
if (index == 0)
{
id = id.substring(1);
}
So I don't understand why that's not working in your case. If the IDREF
fails to resolve initially, it should be deferred as a forward reference
and another attempt to resolve it should be made when the document
ends. The same document proxy issue comes up when there are references
of the form <baseURI>#<fragment> where <baseURI> is the same as the
containing resource's URI and hence in the case that the reference
really should have looked like #<fragment>.
In general, you should feel free to extend anything in the XMI plugin.
If you look in our own code base, you'll see we do that ourselves in
many places. We try very hard to treat all these things as API and to
introduce no breaking changes.
The namespace for the package during serialization is determined by the
value of EPackage.nsURI. XMLHandler.createTopObject is called during
deserialization. I'm not sure I follow the last part of your
questions. If package X contains package Y then X and Y must be in the
same resource. Adding Y to another resource will remove it from X
because the Resource to EObject contents relation is handled as a
containment.
I'll be very interested to learn more about your experience with
implenting the EMF APIs directly as opposed to reusing our implementations.
Arti wrote:
> Thanks Ed,
> --We have already implemented all ecore interfaces
> (EObject,InternalEObject,EReference etc..) Also, our EXTERNALID is an
> EAttribute with its isId set to true.
> --You have said that same document proxies should be handled by
> itself. But, it looks like we have to extend some methods of ecore's
> XMLHelperImpl to handle this. We have observed that somehow the
> setValueFromId method of the XMLHandler requires that there be a '#'
> in the representation of references,otherwise it invokes helper's
> setValue with a 'null' in place of the referenced object's id. To get
> that '#' we have extended helper's getIDRef method. Would like to know
> if there is any documentation available, that mentions which of
> ecore's implementations can/should be extended by the users.
> --We are also facing some trouble with the namespaces and top element
> container. 1)while exporting , how is the namespace for a package
> decided 2)while importing,where does the top element get created ?
> e.g. we have a package 'X' that contains package 'Y'. The package 'Y'
> contains many other packages,objects etc. Now, when we export only
> package 'Y', we define the resource as this package. If we import this
> document, where should package 'Y' be created.What should be defined
> as the resource.
> Thanks for all your time and effort. Arti
--------------090301040004040500050301
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Arti,<br>
<br>
The handling of #<ID> and <ID> should be the <font
color="#3333ff">same</font>:<br>
<blockquote><small>
|
|
| |
| Re: using ecore save and load [message #394126 is a reply to message #394119] |
Tue, 05 July 2005 09:40 |
| Eclipse User |
|
|
|
Arti,
For 1) you mean the xsi:type? If the type of the instance is different
from the type expected/declared by the feature, i.e., a derived type,
then an xsi:type is necessary for creating the right type of instance.
The prefix is resolved to a namespace and that namespace is used to
lookup an EPackage which is then used to lookup the classifier name.
For 2), this is exactly how XML Schema works as well, i.e., the
namespace is used to lookup an schema which is then used to lookup the
type with the given name. I don't understand the last part of 2).
Types are contained by a package, but instances, in general, are not
contained by a package. You'll need to elaborate on your question,
because I'm not understanding it at all. For 3), you can see how it's
used in EMOFResourceFactoryImpl and a more complex example is in the
org.eclipse.emf.mapping.ecore2xml plugin, for which Kenn still needs to
write a paper.
Arti wrote:
> Hi Ed,
>
> We have more or less succeeded in doing a basic export/import, barring
> few problems related with containment and type related factories.
>
> The doubts are as follows :
>
> 1)Why are type's prefixed ? e.g. <contains
> xsi:type="com.ttt.aaaa.MetaModel:Association"
> Name="Column.MapsTo.Attribute"......./>
>
> How does EMF XMI (ecore) evaluate this prefix during serialization?
>
> 2)While deserializing the exported file from using ecore import we
> observed that the import gets the factory for creating an object,from
> its type's prefix.
>
> Why is it done like this?
> In our case classes and their instances may not be contained in the
> same package, hence an object and its type may be in two different
> packages.
> But due to ecore's way of fetching factory from type's prefix (which
> we are assuming to be evaluated as the type's/class's container) , it
> always creates instances in the package which contains type (instead
> of the object's package).
>
> Does ecore give any control to us to change this behaviour. Can you
> elaborate on how to do this.
>
> 3)Where can I get information/examples on how to use XMLMap, XMLInfo.
> Thanks
> Arti
>
>
>
|
|
| | | | |
| Re: using ecore save and load [message #394219 is a reply to message #394218] |
Thu, 07 July 2005 10:25 |
| Eclipse User |
|
|
|
Arti,
Your factory should create a fresh new instance, not one that's been
populated with children or parents. You'll have problems in many places
if you don't do this, such as when using EcoreUtil.copy, or when using
child creation or copy commands. I think you should avoid this problem
rather than fixing the places where problems turn up.
Many people do override anything and everything in the XMI plugin. We
are very sensitive to the fact that all our classes are treated as API
by someone and we (try to) avoid any breaking changes. But I still
think you should change your design to not have this problem in the
first place.
Arti wrote:
> Ed,
>
> What you say is correct and that's exactly what we want. In the
> example the reason why "AA" is not getting contained in the "Omgen
> Meta Model" package instance is that we have defined instances to be
> contained in a package by default.So, when "AA" is created we do not
> leave the instance by itself, we make it contained in a package. We
> assume that this package should come from the factory which is being
> used to create the instance.
> Since the factory is created from the package which contains the
> 'type' of the instance, it gets created in the wrong package.
>
> We are considering to extend a few methods which would give us control
> over getting the last 'package' in context. For this we would also
> need to track whether the last 'package' element created in context
> has reached its 'endElement'. Something similar to the way XMLHandler
> maintains an 'objects' stack.
>
> Is it advisable to extend any of the XMLHandler methods, particularly
> 'createObjectFromType' or 'getFactoryFromPrefix'? Is the XMLHandler
> code likely to change often. If we extend the handler would we need to
> worry about new code versions of the handler. Please tell us if this
> would be a feasible(and good) approach.
>
> Thanks
> Arti
>
>
> Ed Merks wrote :
>
>> I'm still confused and I think it's because you are mixing meta and
>> instance. Creating the "AA" instance will (should) result in an
>> instance not contained by anything. For an example like the one
>> below, a Package instance named "Omgen Meta Model" should be created
>> and under that a Class instance named "AA" should be created and that
>> "AA" instance should be added to the "contains" feature of "Omgen
>> Meta Model". That's what I expect and I'm pretty sure that's what
>> you want. So I'm not sure where first the wires are getting crossed.
>
>
> ============================================================ ==============
> <?xml version="1.0" encoding="ASCII"?>
> <com.ttt.aaaa.MetaMetaModel:Package xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:com.ttt.aaaa.MetaMetaModel="com.ttt.aaaa.MetaMetaModel "
> Name="Omgen Meta Model" URL="com.ttt.OMGEN.MetaModel"
> container="#com.ttt.aaaa.omgentoppkg">
> <contains xsi:type="com.ttt.aaaa.MetaMetaModel:Class" Name="AA"
> uniqueId=" com.ttt.aaaa.MetaMetaModel.Class:9277b20bcd7854de6e2577898f3 44986c6a3e631d3b31e068f6f4725dc13443a "
> isAbstract="N" isNameId="Y"
> attribute=" #com.ttt.aaaa.MetaMetaModel.Property:154b2d926f8719154636228 935bd2c2996039c8ce8a5d01131dc008e7e7c6f87
> "
> inheritedBy=" #com.ttt.aaaa.MetaMetaModel.Class:a4207925c29b812a6693c121cf 00fb021e1504f21ff277eb608572f285930263
> #com.ttt.aaaa.MetaMetaModel.Class:3935a093fb1a76f019a8b4c730 aefde0a1f966b601aa07fd2daab2b0193b648f "
> targetOf=" #com.ttt.aaaa.MetaMetaModel.Association:6b0691a68889a07aaa16 0544b8eeffde8a0c8cf079f6270a898e03ccd006fcdb
> />
> ============================================================ =============
>
|
|
|
| Re: using ecore save and load [message #394226 is a reply to message #394219] |
Fri, 08 July 2005 09:52 |
| Eclipse User |
|
|
|
Originally posted by: arti_subscribe.rediffmail.com
Ed,
As per EMOF of MOF
1)Package contains Types
2)Instances of Types , themself can acts as Types.
e.g
Type is Class , we create some instance of Class ,say 'Employee'.Now
'Employee' itself can be type.
So essentially there is no fixed meta and instance layering. It can go at
any level.
Q 1 >So how does emf export such a model?
can you give some example.
Q 2> Considering the fact 2) mentioned above,the created instances also
need to be part of some package.
How does EMF handle this?
Thanks
Arti
Ed Merks wrote:
> Arti,
> Your factory should create a fresh new instance, not one that's been
> populated with children or parents. You'll have problems in many places
> if you don't do this, such as when using EcoreUtil.copy, or when using
> child creation or copy commands. I think you should avoid this problem
> rather than fixing the places where problems turn up.
> Many people do override anything and everything in the XMI plugin. We
> are very sensitive to the fact that all our classes are treated as API
> by someone and we (try to) avoid any breaking changes. But I still
> think you should change your design to not have this problem in the
> first place.
|
|
|
| Re: using ecore save and load [message #394227 is a reply to message #394226] |
Fri, 08 July 2005 11:34 |
| Eclipse User |
|
|
|
Arti,
Meta meta levels! My favorite word game. ;-)
If you have an EObject x, you can do x.eClass(), x.eClass().eClass(),
x.eClass().eClass().eClass(), and so on, to any level. Mind you,
x.eClass().eClass() == x.eClass().eClass().eClass() because it's
Ecore.eINSTANCE.getEClass() which is it's own class. EMF only exports
EObjects, so if you create your own meta model, e.g., the XSD model for
XML Schema, for which instances are not EObjects, e.g., DOM, then EMF
does not help you export instances. So the answer to your first question
depends on whether "Employee" is an EObject. In terms of your second
question, when you create an EClass,
EcoreFactory.eINSTANCE.createEClass(), you can (need to) create an
EPackage, EcoreFactory.eINSTANCE.createEPackage(), to put it in; we do
not automatically create an EPackage when we create an EClass because
typically a bunch of classes will be put in a single package and because
when we read in a model, we expect to read in a package containing
classes, not classes all by themselves.
Arti wrote:
> Ed,
>
> As per EMOF of MOF
> 1)Package contains Types
> 2)Instances of Types , themself can acts as Types.
> e.g
> Type is Class , we create some instance of Class ,say 'Employee'.Now
> 'Employee' itself can be type.
>
> So essentially there is no fixed meta and instance layering. It can go
> at any level.
>
> Q 1 >So how does emf export such a model?
> can you give some example.
>
> Q 2> Considering the fact 2) mentioned above,the created instances
> also need to be part of some package.
> How does EMF handle this?
>
> Thanks
> Arti
>
> Ed Merks wrote:
>
>> Arti,
>
>
>> Your factory should create a fresh new instance, not one that's been
>> populated with children or parents. You'll have problems in many
>> places if you don't do this, such as when using EcoreUtil.copy, or
>> when using child creation or copy commands. I think you should
>> avoid this problem rather than fixing the places where problems turn up.
>
>
>> Many people do override anything and everything in the XMI plugin.
>> We are very sensitive to the fact that all our classes are treated as
>> API by someone and we (try to) avoid any breaking changes. But I
>> still think you should change your design to not have this problem in
>> the first place.
>
>
>
>
>
|
|
| | | |
| Re: using ecore save and load [message #394329 is a reply to message #394327] |
Fri, 15 July 2005 08:10 |
| Eclipse User |
|
|
|
Arti,
For 1), yes, XMIResourceImpl will create a single root element to hold
the multiple Resource.getContents() objects, if there are multiple. For
2), something that starts with <? is a processing instruction and not an
element. For 3), if Resource.getContents().size() == 1 you get the
first format, otherwise you'll get the second format.
Arti wrote:
> Hi Ed,
>
> Does EMF's XMI implementation have any restriction on number of 'top'
> elements.
>
> Q 1) Can I serialize in a way such that the xml doc looks like :-
>
> <?xml version="1.0" encoding="ASCII"?>
> <xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
> xmlns:myns="com.ttt.aaaa">
> <top elem1 ..... />
> <top elem2 ..... />
> <top elem3 ..... />
> <top elem4 ..... />
> </xmi:XMI>
>
> XMI says that one root element should be there, but doesn't specify
> any restriction on top elements. (assuming that 'root' and 'top' mean
> different things.
>
> Q 2) What is considered as a 'root' element here. <?xml version="1.0"
> encoding="ASCII"?>
> OR <xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
> xmlns:myns="com.ttt.aaaa">
>
>
> Q 3) How does EMF control serialization in different formats as given
> below :-
>
> format 1)
> <?xml version="1.0" encoding="ASCII"?>
> <myns:Package xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
> xmlns:myns="com.ttt.aaaa" Name="UML Meta Model" URL="com.ttt.uml1_3"
>
>>
>
> format 2)
> <?xml version="1.0" encoding="ASCII"?>
> <xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
> xmlns:myns="com.ttt.aaaa">
> <myns:Package Name="UML Meta Model" URL="com.ttt.uml1_3"
>
>>
>
>
>
> Thanks
> Arti
>
>
|
|
|
| Re: using ecore save and load [message #394441 is a reply to message #394329] |
Wed, 20 July 2005 09:37 |
| Eclipse User |
|
|
|
Originally posted by: arti_subscribe.rediffmail.com
Hi Ed,
A few questions related to interoperability with EMF
------------------------------------------------------------ --------------
We have a MOF compliant repository. So when we create any metamodel , we
create instances of MOF classes ( MOF's meta meta model ). e.g when we
model UML meta model's State ,Transition , we create instance of MOF class
"Class".
To export this meta model, we are using EMF's XMI Export/Import. But when
we export we get the meta model as instance of MOF meta meta model.
------------------------------------------------------------ --------------
Questions:
1) Now we want interoperability with EMF. EMF expects metamodel in
".ecore" , which essentially specifies meta model as instances of Ecore.
Does EMF have any support for exporting MOF meta models in EMF Ecore form
or the other way round (i.e import MOF meta model)
2)While going through ecore's XMI implementation , we found some classes :
EMOFResourceImpl,EMOFResourceFactoryImpl,EMOFExtendedMetaDat a,EMOFSaveImpl.
What is the purpose of these classes. How can they be used ?
Thanks
Arti
|
|
|
| Re: using ecore save and load [message #394443 is a reply to message #394441] |
Wed, 20 July 2005 09:51 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------060002030402000806010100
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Arti,
There's support for EMOF, i.e., EMOFResourceFactoryImpl is registered to
handle files with .emof extension. I produces a resource implementation
that will parse the contents directly as an Ecore instance and will save
them an EMOF serialization. So if you put an EPackage into an
EMOFResourceImpl, it will be serialized as EMOF. The Sample Ecore
Editor does the resource implementation switching if you do Save As and
pick .emof for the extension:
public void doSaveAs()
{
SaveAsDialog saveAsDialog= new SaveAsDialog(getSite().getShell());
saveAsDialog.open();
IPath path= saveAsDialog.getResult();
if (path != null)
{
IFile file =
ResourcesPlugin.getWorkspace().getRoot().getFile(path);
if (file != null)
{
ResourceSet resourceSet = editingDomain.getResourceSet();
Resource currentResource =
(Resource)resourceSet.getResources().get(0);
String currentExtension =
currentResource.getURI().fileExtension();
URI newURI =
URI.createPlatformResourceURI(file.getFullPath().toString()) ;
String newExtension = newURI.fileExtension();
if (currentExtension.equals(ECORE_FILE_EXTENSION) &&
newExtension.equals(EMOF_FILE_EXTENSION) ||
currentExtension.equals(EMOF_FILE_EXTENSION) &&
newExtension.equals(ECORE_FILE_EXTENSION))
{
Resource newResource = resourceSet.createResource(newURI);
newResource.getContents().addAll(currentResource.getContents ());
resourceSet.getResources().remove(0);
resourceSet.getResources().move(0, newResource);
}
else
{
currentResource.setURI(newURI);
}
IFileEditorInput modelFile = new FileEditorInput(file);
setInput(modelFile);
setPartName(file.getName());
doSave(getActionBars().getStatusLineManager().getProgressMon itor());
}
}
}
Arti wrote:
> Hi Ed,
>
> A few questions related to interoperability with EMF
>
> ------------------------------------------------------------ --------------
>
> We have a MOF compliant repository. So when we create any metamodel ,
> we create instances of MOF classes ( MOF's meta meta model ). e.g when
> we model UML meta model's State ,Transition , we create instance of
> MOF class "Class".
>
> To export this meta model, we are using EMF's XMI Export/Import. But
> when we export we get the meta model as instance of MOF meta meta model.
>
> ------------------------------------------------------------ --------------
>
>
> Questions:
>
> 1) Now we want interoperability with EMF. EMF expects metamodel in
> ".ecore" , which essentially specifies meta model as instances of Ecore.
>
> Does EMF have any support for exporting MOF meta models in EMF Ecore
> form or the other way round (i.e import MOF meta model)
>
> 2)While going through ecore's XMI implementation , we found some
> classes :
> EMOFResourceImpl,EMOFResourceFactoryImpl,EMOFExtendedMetaDat a,EMOFSaveImpl.
>
>
> What is the purpose of these classes. How can they be used ?
>
> Thanks
> Arti
>
--------------060002030402000806010100
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Arti,<br>
<br>
There's support for EMOF, i.e., EMOFResourceFactoryImpl is registered
to handle files with .emof extension.
|
|
| | |
| Re: using ecore save and load [message #394495 is a reply to message #394443] |
Fri, 22 July 2005 08:57 |
| Eclipse User |
|
|
|
Originally posted by: arti_subscribe.rediffmail.com
Ed,
1)Is there any support for CMOF as well ? We are facing some problems with
"Association". Since, a CMOF "Association" is equivalent to two EMOF
"Property".
2)The extendedMetaData's xml map created in EMOFResourceFactoryImpl
contains a mapping from ecore constructs to EMOF Names and this map is
used to fetch names for any ecore classes (using
extendedmetadata.getName(eClass)).
During de-serialization how is the ecore class fetched from an EMOF name
(the reverse of the above).e.g. Since EAttribute and EReference are both
"Property", while de-serializing how is the correct eClass obtained for
"Property"
------------------------------------------------------------ -----------
xmlMap.add(EcorePackage.eINSTANCE.getEAttribute(),
createXMLInfo("Property"));
xmlMap.add(EcorePackage.eINSTANCE.getEReference(),
createXMLInfo("Property"));
------------------------------------------------------------ -----------
Thanks
Arti
Ed Merks wrote:
> Arti,
> There's support for EMOF, i.e., EMOFResourceFactoryImpl is registered to
> handle files with .emof extension. I produces a resource implementation
> that will parse the contents directly as an Ecore instance and will save
> them an EMOF serialization. So if you put an EPackage into an
> EMOFResourceImpl, it will be serialized as EMOF. The Sample Ecore
> Editor does the resource implementation switching if you do Save As and
> pick .emof for the extension:
> public void doSaveAs()
> {
> SaveAsDialog saveAsDialog= new SaveAsDialog(getSite().getShell());
> saveAsDialog.open();
> IPath path= saveAsDialog.getResult();
> if (path != null)
> {
> IFile file =
> ResourcesPlugin.getWorkspace().getRoot().getFile(path);
> if (file != null)
> {
> ResourceSet resourceSet = editingDomain.getResourceSet();
> Resource currentResource =
> (Resource)resourceSet.getResources().get(0);
> String currentExtension =
> currentResource.getURI().fileExtension();
> URI newURI =
> URI.createPlatformResourceURI(file.getFullPath().toString()) ;
> String newExtension = newURI.fileExtension();
> if (currentExtension.equals(ECORE_FILE_EXTENSION) &&
> newExtension.equals(EMOF_FILE_EXTENSION) ||
> currentExtension.equals(EMOF_FILE_EXTENSION) &&
> newExtension.equals(ECORE_FILE_EXTENSION))
> {
> Resource newResource = resourceSet.createResource(newURI);
> newResource.getContents().addAll(currentResource.getContents ());
> resourceSet.getResources().remove(0);
> resourceSet.getResources().move(0, newResource);
> }
> else
> {
> currentResource.setURI(newURI);
> }
> IFileEditorInput modelFile = new FileEditorInput(file);
> setInput(modelFile);
> setPartName(file.getName());
> doSave(getActionBars().getStatusLineManager().getProgressMon itor());
> }
> }
> }
> Arti wrote:
>> Hi Ed,
>>
>> A few questions related to interoperability with EMF
>>
>> ------------------------------------------------------------ --------------
>>
>> We have a MOF compliant repository. So when we create any metamodel ,
>> we create instances of MOF classes ( MOF's meta meta model ). e.g when
>> we model UML meta model's State ,Transition , we create instance of
>> MOF class "Class".
>>
>> To export this meta model, we are using EMF's XMI Export/Import. But
>> when we export we get the meta model as instance of MOF meta meta model.
>>
>> ------------------------------------------------------------ --------------
>>
>>
>> Questions:
>>
>> 1) Now we want interoperability with EMF. EMF expects metamodel in
>> ".ecore" , which essentially specifies meta model as instances of Ecore.
>>
>> Does EMF have any support for exporting MOF meta models in EMF Ecore
>> form or the other way round (i.e import MOF meta model)
>>
>> 2)While going through ecore's XMI implementation , we found some
>> classes :
>> EMOFResourceImpl,EMOFResourceFactoryImpl,EMOFExtendedMetaDat a,EMOFSaveImpl.
>>
>>
>> What is the purpose of these classes. How can they be used ?
>>
>> Thanks
>> Arti
>>
|
|
|
| Re: using ecore save and load [message #394496 is a reply to message #394495] |
Fri, 22 July 2005 09:42 |
| Eclipse User |
|
|
|
Arti,
There is no support for CMOF. Like EMOF, Ecore has EReferences with
eOpposite to pair them up to represent two ends of an association. Your
second question is best answered by stepping through the code. Stepping
through EMOFHelperImpl.createObject will answer the first part and
stepping through EMOFHelperImpl.convertPropertyFeatures will answer the
second part.
Arti wrote:
> Ed,
>
> 1)Is there any support for CMOF as well ? We are facing some problems
> with "Association". Since, a CMOF "Association" is equivalent to two
> EMOF "Property".
> 2)The extendedMetaData's xml map created in EMOFResourceFactoryImpl
> contains a mapping from ecore constructs to EMOF Names and this map is
> used to fetch names for any ecore classes (using
> extendedmetadata.getName(eClass)).
> During de-serialization how is the ecore class fetched from an EMOF
> name (the reverse of the above).e.g. Since EAttribute and EReference
> are both "Property", while de-serializing how is the correct eClass
> obtained for "Property"
> ------------------------------------------------------------ -----------
> xmlMap.add(EcorePackage.eINSTANCE.getEAttribute(),
> createXMLInfo("Property"));
> xmlMap.add(EcorePackage.eINSTANCE.getEReference(),
> createXMLInfo("Property"));
> ------------------------------------------------------------ -----------
>
>
> Thanks
> Arti
>
>
>
> Ed Merks wrote:
>
>> Arti,
>
>
>> There's support for EMOF, i.e., EMOFResourceFactoryImpl is registered
>> to handle files with .emof extension. I produces a resource
>> implementation that will parse the contents directly as an Ecore
>> instance and will save them an EMOF serialization. So if you put an
>> EPackage into an EMOFResourceImpl, it will be serialized as EMOF.
>> The Sample Ecore Editor does the resource implementation switching if
>> you do Save As and pick .emof for the extension:
>
>
>> public void doSaveAs()
>> {
>> SaveAsDialog saveAsDialog= new
>> SaveAsDialog(getSite().getShell());
>> saveAsDialog.open();
>> IPath path= saveAsDialog.getResult();
>> if (path != null)
>> {
>> IFile file =
>> ResourcesPlugin.getWorkspace().getRoot().getFile(path);
>> if (file != null)
>> {
>> ResourceSet resourceSet = editingDomain.getResourceSet();
>> Resource currentResource =
>> (Resource)resourceSet.getResources().get(0);
>> String currentExtension =
>> currentResource.getURI().fileExtension();
>
>
>> URI newURI =
>> URI.createPlatformResourceURI(file.getFullPath().toString()) ;
>> String newExtension = newURI.fileExtension();
>
>
>> if (currentExtension.equals(ECORE_FILE_EXTENSION) &&
>> newExtension.equals(EMOF_FILE_EXTENSION) ||
>> currentExtension.equals(EMOF_FILE_EXTENSION) &&
>> newExtension.equals(ECORE_FILE_EXTENSION))
>> {
>> Resource newResource = resourceSet.createResource(newURI);
>
>
>> newResource.getContents().addAll(currentResource.getContents ());
>> resourceSet.getResources().remove(0);
>> resourceSet.getResources().move(0, newResource);
>> }
>> else
>> {
>> currentResource.setURI(newURI);
>> }
>
>
>> IFileEditorInput modelFile = new FileEditorInput(file);
>> setInput(modelFile);
>> setPartName(file.getName());
>
>
>> doSave(getActionBars().getStatusLineManager().getProgressMon itor());
>> }
>> }
>> }
>
>
>
>> Arti wrote:
>
>
>>> Hi Ed,
>>>
>>> A few questions related to interoperability with EMF
>>>
>>> ------------------------------------------------------------ --------------
>>>
>>> We have a MOF compliant repository. So when we create any metamodel
>>> , we create instances of MOF classes ( MOF's meta meta model ). e.g
>>> when we model UML meta model's State ,Transition , we create
>>> instance of MOF class "Class".
>>>
>>> To export this meta model, we are using EMF's XMI Export/Import. But
>>> when we export we get the meta model as instance of MOF meta meta
>>> model.
>>>
>>> ------------------------------------------------------------ --------------
>>>
>>>
>>> Questions:
>>>
>>> 1) Now we want interoperability with EMF. EMF expects metamodel in
>>> ".ecore" , which essentially specifies meta model as instances of
>>> Ecore.
>>>
>>> Does EMF have any support for exporting MOF meta models in EMF Ecore
>>> form or the other way round (i.e import MOF meta model)
>>>
>>> 2)While going through ecore's XMI implementation , we found some
>>> classes :
>>> EMOFResourceImpl,EMOFResourceFactoryImpl,EMOFExtendedMetaDat a,EMOFSaveImpl.
>>>
>>>
>>> What is the purpose of these classes. How can they be used ?
>>>
>>> Thanks
>>> Arti
>>>
>
>
|
|
| | |
| Re: using ecore save and load [message #394524 is a reply to message #394519] |
Tue, 26 July 2005 09:12 |
| Eclipse User |
|
|
|
Arti,
As far as I know, there aren't any major non-conformances, but the spec
is massive and we may well not support every last feature directly
exactly the way you might expect.
I suppose EMF is an open tool, although I find the definition a bit
strange. An object can only have one xmi:uuid and EMF doesn't care what
form that ID takes. With options like
XMLResource.OPTION_RECORD_UNKNOWN_FEATURE you can parse pretty much well
formed XML to record all the "unexpected" data on the side and to be
able to save it again later.
EMF supports modeled/intrinsic IDs via EAttribute.isID, where the object
has a feature whose value is used as an ID, and extrinsic IDs, where the
Resource manages the ID associated with the object via
XMLResource.getID/setID. If you override XMLResourceImpl.useUUIDs to
return true, EMF will generate UUIDs automatically as objects are added
to the resource. The UML2 project takes advantage of this UUID support.
As Chris pointed out, EMF has a Change model that can record all changes
make to a set of objects.
EMF allows you to suppress the visibility of accessor methods in the
generated interface via annotations as produced by
EcoreUtil.setSupressedVisibility. Reflectively, all features are always
"visible".
We have no plans to support CMOF, but if there are interesting/useful
features we could support related to this we'll reconsider.
Arti wrote:
> Ed,
>
> We understand that EMF is compatible with XMI 2.0.
> Are there any non-conformances with XMI 2.0 ?
>
> How are the following dealt with in EMF's XMI import/export
> implementation
>
> A) Document Exchange with Multiple Tools (section 1.13 of XMI 2.0 specs)
> ------------------------------------------------------------ ---------------
>
> (I have pasted a part of this section at the end of my query)
> Q1) is EMF an open or closed tool ? is it compatible with both kinds
> of tools
> Q2) how does EMF deal with different 'id' implementation in different
> tools during import/export across tools. Does it have any xmi:uuid or
> extenderId.
>
> B) delta model - differences model in xmi
> ------------------------------------------------------------ ---------------
>
> Q3) Does EMF support a 'differences model'.(section 1.12 of XMI 2.0
> specs)
>
>
> C) visibility
> ------------------------------------------------------------ ---------------
>
> Q4) does EMF not treat 'visibility' as a modelled property of a named
> element ?
>
> D) cmof support in future
> ------------------------------------------------------------ ---------------
>
> Q5) Is there support for CMOF planned in the future
>
>
>
> Thanks
> Arti
>
>
> ************************************************************ ******************
>
>
> 1.13 Document Exchange with Multiple Tools
> This section contains a recommendation for an optional methodology
> that can be used
> when multiple tools interchange documents. In this methodology, the
> xmi:uuid and
> extensions are used together to preserve tool-specific information. In
> particular, tools
> may have particular requirements on their IDs that make ID interchange
> difficult.
> Extensions are used to hold tool-specific information, including
> tool-specific IDs.
> The basic policy is that the XML ID is assigned by the tool that
> initially creates a
> construct. The UUID will most likely be the same as the ID the tool
> would choose for
> its own use. Any other modifiers of the document must preserve the
> original UUID,
> but may add their own as part of their extensions.
> 1.13.1 Definitions
> General:
> � MC - Model construct. An XML element that contains an xmi.uuid
> attribute.
> � Extension - Extensions use the extension element. Extensions to MCs
> may be
> nested in MCs, linked to the extensions section(s) of the document, or
> linked
> outside the document. Each extension contains a tool-specific
> identifier in the
> extender attribute. Extensions are considered private to a particular
> tool. An MC
> may have zero or more extensions. Extensions may be nested.
> IDs:
> � xmi:uuid - The universally unique ID of an MC, expressed as the
> xmi:uuid
> attribute. Example: <Class xmi:uuid=�ABCDEFGH�>
> � extenderID - The tool-specific ID of an MC. The extenderID is stored
> in an
> extension of the MC when it differs from the xmi:uuid.
> Tool ID policies:
> Every tool is either Open or Closed.
> � Open tool - A tool that will accept any xmi:uuid as its own. Open
> tools do not need
> to add extensions to contain a tool-specific id.
> � Closed tool - A tool that will not accept an xmi:uuid created by
> another tool.
> Closed tools store their ids in the extenderID attribute of an
> XMI.extension. The
> extender attribute of the XMI.extension is set to the name of the
> closed tool.
>
> ************************************************************ ******************
>
>
|
|
|
| Re: using ecore save and load [message #394548 is a reply to message #394524] |
Wed, 27 July 2005 09:46 |
| Eclipse User |
|
|
|
Originally posted by: arti_subscribe.rediffmail.com
Hi,
A few more questions...
1) Does EMF give us any handle to specify our own 'extensions', so that
tool specific information can be specified (as given in xmi 2.0 specs) ?
The EMOFExtendedMetaData has the following for setting the extension
information for Ecore.It seems to parse the extension info, but ignores it
after parsing.
------------------------------------------------------------ ----------------
public static final String XMI_EXTENSION_ELEMENT = XMIResource.XMI_NS +
":" + EXTENSION;
public static final String XMI_EXTENDER_ATTRIBUTE = "extender";
public static final String EMOF_XMI_EXTENDER = EcorePackage.eNS_URI;
------------------------------------------------------------ ----------------
2) Since EMF supports only EMOF , we are trying to implement conversion
for one CMOF 'Association' to two EMOF 'Property' and vice versa.
During de-serialization the conversion can be done only in the end so that
the complete model and information is available. We have extended only the
Resource and Helper implementations. Not extended the 'Handler'. It seems
that the handler is the only one to have information whether the 'end
document' has been reached.
Where, in the EMF code, can we get a handle to implement the conversion.
(A similar conversion is implemented in the EMF code
'convertPropertyFeatures' to convert 'Property' to either EAttribute or
EReference. But this is done in the handler.)
Can you suggest any way, so that we need not extend the handler.
3)As mentioned in one of my previous queries, deferring ID resolution to
end was possible only if the references were of the form feature=#<ID> and
not if we remove the '#'. In the latest sources there is a flag "boolean
mustAdd = deferIDREFResolution;", to defer this explicitly and hence does
not require the '#'. Is it that if we use Eclipse 3.0 and ecore 2.0 we
have to explicitly add a '#',because these sources do not have the
'deferIDREFResolution' flag.
If we use new sources do we always have to externally set the
'deferIDREFResolution' flag to true.
4)How are dangling references handled while importing a third party tool's
xmi doc. Since ids of all tools will differ, does EMF have any mechanism
to process these dangling refs.
5)The XMLResource in EMF maintains two maps eObjectToIDmap and
idToEObjectmap
for getting an eobject corresponding to an id and vice versa.Is it assumed
that the ids in any document being de-serialized will be unique and there
will be no conflicts while using this map.
Thanks
Arti
|
|
|
| Re: using ecore save and load [message #394554 is a reply to message #394548] |
Wed, 27 July 2005 10:22 |
| Eclipse User |
|
|
|
Arti,
For 1), extensions won't be recognized unless you add special handling
for them. If you use XMLResource.OPTION_RECORD_UNKNOWN_FEATURE you can
record the information and then access the additional data via
XMLResource.getEObjectToExtensionMap(). The data in this map will be
saved, so this is also the way to add extensions.
Extending the handler is the only way to do 2).
For 3), you could use XMLResource.OPTION_DEFER_IDREF_RESOLUTION as a
default load option set by the resource factory when first it creates
the resource so that all your instance resource will do that by
default. EMF 2.0 did not support this feature...
I don't understand 4), i.e., I don't understand this notion of each tool
adding its own ID(s) that no one else knows are IDs. In any case,
dangling references typically become unresolvable proxies, except for
same document references, which are handled by handleForwardReferences
and produce errors for failure to resolve; a document is just
inconsistent if it doesn't reference other parts of itself correctly.
For 5), yes it is assumed that IDs are unique; it's not an ID if that's
not the case.
Arti wrote:
> Hi,
>
> A few more questions...
>
> 1) Does EMF give us any handle to specify our own 'extensions', so
> that tool specific information can be specified (as given in xmi 2.0
> specs) ?
> The EMOFExtendedMetaData has the following for setting the extension
> information for Ecore.It seems to parse the extension info, but
> ignores it after parsing.
> ------------------------------------------------------------ ----------------
>
> public static final String XMI_EXTENSION_ELEMENT = XMIResource.XMI_NS
> + ":" + EXTENSION;
> public static final String XMI_EXTENDER_ATTRIBUTE = "extender";
> public static final String EMOF_XMI_EXTENDER = EcorePackage.eNS_URI;
> ------------------------------------------------------------ ----------------
>
>
> 2) Since EMF supports only EMOF , we are trying to implement
> conversion for one CMOF 'Association' to two EMOF 'Property' and vice
> versa.
> During de-serialization the conversion can be done only in the end so
> that the complete model and information is available. We have extended
> only the Resource and Helper implementations. Not extended the
> 'Handler'. It seems that the handler is the only one to have
> information whether the 'end document' has been reached.
> Where, in the EMF code, can we get a handle to implement the
> conversion. (A similar conversion is implemented in the EMF code
> 'convertPropertyFeatures' to convert 'Property' to either EAttribute
> or EReference. But this is done in the handler.)
>
> Can you suggest any way, so that we need not extend the handler.
>
> 3)As mentioned in one of my previous queries, deferring ID resolution
> to end was possible only if the references were of the form
> feature=#<ID> and not if we remove the '#'. In the latest sources
> there is a flag "boolean mustAdd = deferIDREFResolution;", to defer
> this explicitly and hence does not require the '#'. Is it that if we
> use Eclipse 3.0 and ecore 2.0 we have to explicitly add a '#',because
> these sources do not have the 'deferIDREFResolution' flag.
> If we use new sources do we always have to externally set the
> 'deferIDREFResolution' flag to true.
>
>
> 4)How are dangling references handled while importing a third party
> tool's xmi doc. Since ids of all tools will differ, does EMF have any
> mechanism to process these dangling refs.
>
> 5)The XMLResource in EMF maintains two maps eObjectToIDmap and
> idToEObjectmap
> for getting an eobject corresponding to an id and vice versa.Is it
> assumed that the ids in any document being de-serialized will be
> unique and there will be no conflicts while using this map.
>
>
> Thanks
> Arti
>
>
|
|
| | | |
| Re: using ecore save and load [message #394620 is a reply to message #394554] |
Sun, 31 July 2005 04:47 |
| Eclipse User |
|
|
|
Originally posted by: arti_subscribe.rediffmail.com
Hi,
In my xmi de-serialization (load) options I have set
XMLResource.OPTION_DEFER_IDREF_RESOLUTION as TRUE, since I want to defer
the resolution of all ids.
I've observed that despite setting the above option as true, the ids don't
get deferred for resolution if they contain a ':'. Is there any
restriction on representation of ids.
Attached XMLHelper.setValueFromId for reference.
else if (id.indexOf(":") != -1)
{
qName = id;
continue;
}
because of this 'if(mustAdd)' is never reached and 'position' always
remains 0.
------------------------------------------------------------ ------------------
protected void setValueFromId(EObject object, EReference eReference,
String ids)
{
StringTokenizer st = new StringTokenizer(ids);
boolean isFirstID = true;
boolean mustAdd = deferIDREFResolution;
boolean mustAddOrNotOppositeIsMany = false;
int size = 0;
String qName = null;
int position = 0;
while (st.hasMoreTokens())
{
String id = st.nextToken();
int index = id.indexOf("#");
if (index != -1)
{
if (index == 0)
{
id = id.substring(1);
}
else
{
Object oldAttributes = setAttributes(null);
// Create a proxy in the correct way and pop it.
//
InternalEObject proxy =
(InternalEObject)
(qName == null ?
createObjectFromFeatureType(object, eReference) :
createObjectFromTypeName(object, qName, eReference));
setAttributes(oldAttributes);
handleProxy(proxy, id);
objects.pop();
types.pop();
mixedTargets.pop();
qName = null;
++position;
continue;
}
}
else if (id.indexOf(":") != -1)
{
qName = id;
continue;
}
if (!deferIDREFResolution)
{
if (isFirstID)
{
EReference eOpposite = eReference.getEOpposite();
mustAdd = eOpposite == null || eOpposite.isTransient() ||
eReference.isMany();
mustAddOrNotOppositeIsMany = mustAdd || !eOpposite.isMany();
isFirstID = false;
}
if (mustAddOrNotOppositeIsMany)
{
EObject resolvedEObject = xmlResource.getEObject(id);
if (resolvedEObject != null)
{
setFeatureValue(object, eReference, resolvedEObject);
qName = null;
++position;
continue;
}
}
}
if (mustAdd)
{
if (size == capacity)
growArrays();
identifiers[size] = id;
positions[size] = position;
++size;
}
qName = null;
++position;
}
if (position == 0)
{
setFeatureValue(object, eReference, null, -2);
}
else if (size <= REFERENCE_THRESHOLD)
{
for (int i = 0; i < size; i++)
{
SingleReference ref = new SingleReference
(object,
eReference,
identifiers[i],
positions[i],
getLineNumber(),
getColumnNumber());
forwardSingleReferences.add(ref);
}
}
else
{
Object[] values = new Object[size];
int[] currentPositions = new int[size];
System.arraycopy(identifiers, 0, values, 0, size);
System.arraycopy(positions, 0, currentPositions, 0, size);
ManyReference ref = new ManyReference
(object,
eReference,
values,
currentPositions,
getLineNumber(),
getColumnNumber());
forwardManyReferences.add(ref);
}
}
------------------------------------------------------------ ------------------
thanks
Arti
|
|
| | |
| Re: using ecore save and load [message #394646 is a reply to message #394620] |
Tue, 02 August 2005 10:04 |
| Eclipse User |
|
|
|
Arti,
The reference is assumed to be a QName, ID/anyURI pair (or list of such
pairs) where the QName is optional. A valid ID must be an NCName,
i.e., non-colonized name, so the presence of a colon implies it's not an
ID.
Arti wrote:
> Hi,
>
> In my xmi de-serialization (load) options I have set
> XMLResource.OPTION_DEFER_IDREF_RESOLUTION as TRUE, since I want to
> defer the resolution of all ids.
> I've observed that despite setting the above option as true, the ids
> don't get deferred for resolution if they contain a ':'. Is there any
> restriction on representation of ids.
>
> Attached XMLHelper.setValueFromId for reference.
>
> else if (id.indexOf(":") != -1)
> {
> qName = id;
> continue;
> }
> because of this 'if(mustAdd)' is never reached and 'position' always
> remains 0.
>
>
> ------------------------------------------------------------ ------------------
>
>
>
> protected void setValueFromId(EObject object, EReference eReference,
> String ids)
> {
> StringTokenizer st = new StringTokenizer(ids);
>
> boolean isFirstID = true;
> boolean mustAdd = deferIDREFResolution;
> boolean mustAddOrNotOppositeIsMany = false;
>
> int size = 0;
> String qName = null;
> int position = 0;
> while (st.hasMoreTokens())
> {
> String id = st.nextToken();
> int index = id.indexOf("#");
> if (index != -1)
> {
> if (index == 0)
> {
> id = id.substring(1);
> }
> else
> {
> Object oldAttributes = setAttributes(null);
> // Create a proxy in the correct way and pop it.
> //
> InternalEObject proxy =
> (InternalEObject)
> (qName == null ?
> createObjectFromFeatureType(object, eReference) :
> createObjectFromTypeName(object, qName, eReference));
> setAttributes(oldAttributes);
> handleProxy(proxy, id);
> objects.pop();
> types.pop();
> mixedTargets.pop();
>
> qName = null;
> ++position;
> continue;
> }
> }
> else if (id.indexOf(":") != -1)
> {
> qName = id;
> continue;
> }
>
> if (!deferIDREFResolution)
> {
> if (isFirstID)
> {
> EReference eOpposite = eReference.getEOpposite();
> mustAdd = eOpposite == null || eOpposite.isTransient() ||
> eReference.isMany();
> mustAddOrNotOppositeIsMany = mustAdd || !eOpposite.isMany();
> isFirstID = false;
> }
>
> if (mustAddOrNotOppositeIsMany)
> {
> EObject resolvedEObject = xmlResource.getEObject(id);
> if (resolvedEObject != null)
> {
> setFeatureValue(object, eReference, resolvedEObject);
> qName = null;
> ++position;
> continue;
> }
> }
> }
> if (mustAdd)
> {
> if (size == capacity)
> growArrays();
>
> identifiers[size] = id;
> positions[size] = position;
> ++size;
> }
> qName = null;
> ++position;
> }
>
> if (position == 0)
> {
> setFeatureValue(object, eReference, null, -2);
> }
> else if (size <= REFERENCE_THRESHOLD)
> {
> for (int i = 0; i < size; i++)
> {
> SingleReference ref = new SingleReference
> (object,
> eReference,
> identifiers[i],
> positions[i],
> getLineNumber(),
> getColumnNumber());
> forwardSingleReferences.add(ref);
> }
> }
> else
> {
> Object[] values = new Object[size];
> int[] currentPositions = new int[size];
> System.arraycopy(identifiers, 0, values, 0, size);
> System.arraycopy(positions, 0, currentPositions, 0, size);
>
> ManyReference ref = new ManyReference
> (object,
> eReference,
> values,
> currentPositions,
> getLineNumber(),
> getColumnNumber());
> forwardManyReferences.add(ref);
> }
> }
>
> ------------------------------------------------------------ ------------------
>
>
> thanks
> Arti
>
|
|
| | |
| Re: using ecore save and load [message #395036 is a reply to message #394897] |
Tue, 16 August 2005 12:20 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------040707000300060302040404
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Arti,
A proxy must be created, otherwise you'd have no data at all about what
is being referenced. Such unresolveable proxies could be "fixed" up to
refer to Ecore's data types or you could define a package for the speced
nsURI. You might want to add a comment to 76538
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=76538>
about support for EMOF's data types; at the time we implemented our
support, the spec was not final and we had no sample EMOF serializations
to work against...
The type association always serialized as a reference, but the reference
might be an IDREF within the same document, in which case it can be
serialized as an attribute, or it might be a cross document reference,
in which case it is serialized using an element with href=.
Arti wrote:
> Hi,
>
> trying to import(de-serialize) the xmi doc given at the end of my query.
>
> 1) One of the owned attributes 'Name' has a 'type' as PrimitiveType
> with a reference->
> href="http://schema.omg.org/spec/mof/2.0/emof.xmi#String"
> since this is a proxy ideally it should not be created (i.e. it should
> not go through the 'createObject' method of XMLHandler). How can I
> specify that this is a proxy and avoid its creation ?
>
> 2)Why is it that the 'type' (TypedElement_type_Type association)
> sometimes gets serialized as a reference and sometimes as a contained
> element. As given in example below.Is it that for types referring to
> PrimitiveType a contained element is created ?
>
> Thanks
> Arti
>
>
> ------------------------------------------------------------ -----------------
>
>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <emof:Package xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:emof="http://schema.omg.org/spec/mof/2.0/emof.xmi"
> xmi:id="UMLPackage"
> name="UMLPackage">
> <ownedType xmi:type="emof:Class" xmi:id="UMLPackage.UMLClass"
> name="UMLClass">
> <ownedAttribute xmi:id="UMLPackage.UMLClass.uMLAttribute"
> name="uMLAttribute"
> upper="5" type="UMLPackage.UMLAttribute"
> opposite="UMLPackage.UMLAttribute.uMLClass"/>
> <ownedAttribute xmi:id="UMLPackage.UMLClass.Name" name="Name">
> <type xmi:type="emof:PrimitiveType"
> href="http://schema.omg.org/spec/mof/2.0/emof.xmi#String"/>
> </ownedAttribute>
> </ownedType>
> </emof:Package>
--------------040707000300060302040404
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Arti,<br>
<br>
A proxy must be created, otherwise you'd have no data at all about what
is being referenced.
|
|
| | | |
| Re: using ecore save and load [message #395082 is a reply to message #395076] |
Wed, 17 August 2005 10:55 |
| Eclipse User |
|
|
|
Arti,
Defining a feature to be an ID, means that there is no need for an
xmi:id in the serialization since the feature itself stores the ID
value. Serializing both a name and an xmi:id would be redundant.
It's hard to read your document with all the "..." in it. The fact
that all your IDs are not valid XML Schema IDs, i.e., non-colonized
names, is likely a cause of problems. The presence of a : in the ID
will make it look like a QName and that will mess things up.
Arti wrote:
> Hi Ed,
>
> We have our own implementation of Ecore interfaces, and we are using
> ecore-xmi 'save' and 'load'.
>
> Trying to test whether the exported document using our implementation
> of ecore interfaces can be loaded buy the EMF and vice versa.
> To check this interoperability, I have used the tutorial given in EMF
> developer's guide (library model using annotated java interfaces) to
> create a library model and serialize it. Using this document I checked
> whether our implementation can import this.
>
> The doc exported by EMF is:-
> ------------------------------------------------------------ -----
>
> <?xml version="1.0" encoding="ASCII"?>
> <org.eclipse.example.library:Library xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:org.eclipse.example.library="http:///org/eclipse/example/library.ecore"
> name="Test Library"> <writers name="JRR Tolkien" books="Fellowship Of
> the Ring"/> <writers name="Ed Merks" books="Eclipse Unleashed Eclipse
> Modeling Framework"/> <writers name="Dave"/> <books
> title="Fellowship Of the Ring" pages="324" category="ScienceFiction"
> author="JRR Tolkien"/> <books title="Eclipse Unleashed" pages="500"
> category="Biography" author="Ed Merks"/> <books title="Eclipse
> Modeling Framework" pages="645" category="Biography" author="Ed
> Merks"/> </org.eclipse.example.library:Library>
> ------------------------------------------------------------ -----
>
> Questions:-
> 1)
> -For the class 'Writer', I have defined isID property of 'name' as true
> -For the class 'Book', I have defined isID property of 'title' as true
>
> When this model is serialized why is it that 'xmi:id' doesnt appear as
> the the id attributes' name.
>
> The following document is exported by our implementation. EMF is not
> able to load this. Is there any visible mistake ?
>
> <?xml version="1.0" encoding="ASCII"?> <xmi:XMI xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:http...org.eclipse.example.library.ecore="http:///org/eclipse/example/library.ecore">
> <http...org.eclipse.example.library.ecore:Library
> xmi:id="http:///org/eclipse/example/library.ecore.Library.b577"
> name="TestLibrary"
> writers="http:///org/eclipse/example/library.ecore.Writer.e1d5
> http:///org/eclipse/example/library.ecore.Writer.a338
> http:///org/eclipse/example/library.ecore.Writer.2caff"
> books="http:///org/eclipse/example/library.ecore.Book.0f476
> http:///org/eclipse/example/library.ecore.Book.61bb5
> http:///org/eclipse/example/library.ecore.Book.60f52 "/>
> <http...org.eclipse.example.library.ecore:Writer
> xmi:id="http:///org/eclipse/example/library.ecore.Writer.e1d5"
> name="JRRTolkien"
> books="http:///org/eclipse/example/library.ecore.Book.0f476"/>
> <http...org.eclipse.example.library.ecore:Writer
> xmi:id="http:///org/eclipse/example/library.ecore.Writer.a338 "
> name="EdMerks"
> books="http:///org/eclipse/example/library.ecore.Book.61bb5
> http:///org/eclipse/example/library.ecore.Book.60f52 "/>
> <http...org.eclipse.example.library.ecore:Writer
> xmi:id="http:///org/eclipse/example/library.ecore.Writer.2caff"
> name="Dave"/> <http...org.eclipse.example.library.ecore:Book
> xmi:id="http:///org/eclipse/example/library.ecore.Book.0f476"
> title="Fellowship" pages="324"
> author="http:///org/eclipse/example/library.ecore.Writer.e1d5 "/>
> <http...org.eclipse.example.library.ecore:Book
> xmi:id="http:///org/eclipse/example/library.ecore.Book.61bb5"
> title="Eclipse" pages="500"
> author="http:///org/eclipse/example/library.ecore.Writer.a338 "/>
> <http...org.eclipse.example.library.ecore:Book
> xmi:id="http:///org/eclipse/example/library.ecore.Book.60f52 "
> title="EMF" pages="645"
> author="http:///org/eclipse/example/library.ecore.Writer.a338 "/>
> </xmi:XMI>
>
> Thanks
> Arti
>
|
|
|
| Re: using ecore save and load [message #395133 is a reply to message #395082] |
Thu, 18 August 2005 08:36 |
| Eclipse User |
|
|
|
Originally posted by: arti_subscribe.rediffmail.com
Ed Merks wrote:
> Arti,
> Defining a feature to be an ID, means that there is no need for an
> xmi:id in the serialization since the feature itself stores the ID
> value. Serializing both a name and an xmi:id would be redundant.
****Arti***I agree that adding xmi:id in such a case would be redundant.
However, in EMF's code for XMI Import, it is observed that the resource
has two maps associated with it 1) idToObjectMap and 2)eObjectToIDMap
The idToObjectMap is used while resolving references. But, this map is
populated in resource.setID method which is invoked only when the
idattributeName is xmi:id(or a common name at a resource level).
Why isn't this map populated for any class specific id attribute. This
would make reference resolution simpler (Because during resolution, if
this map is null, all objects from the resource's contents are fetched and
each object's id is checked to get the desired referenced object).
reference to SAXXMLHandler code :-
protected void handleObjectAttribs(EObject obj)
{
if (attribs != null)
{
InternalEObject internalEObject = (InternalEObject)obj;
for (int i = 0, size = attribs.getLength(); i < size; ++i)
{
String name = attribs.getQName(i);
if (name.equals(idAttribute))
{
xmlResource.setID(internalEObject, attribs.getValue(i));
}
---
---
---
}
Ed Merks wrote:
> It's hard to read your document with all the "..." in it. The fact
> that all your IDs are not valid XML Schema IDs, i.e., non-colonized
> names, is likely a cause of problems. The presence of a : in the ID
> will make it look like a QName and that will mess things up.
****Arti***Thanks,I was able to import the document in EMF with valid IDs.
|
|
|
| Re: using ecore save and load [message #395186 is a reply to message #395133] |
Mon, 22 August 2005 09:39 |
| Eclipse User |
|
|
|
Arti,
The maps you refer to are only for the extrinsic IDs. There's a
separate map for intrinsic IDs, namely intrinsicIDToEObjectMap, that can
be used to make lookup of intrinsic IDs faster.
Arti wrote:
> Ed Merks wrote:
>
>> Arti,
>> Defining a feature to be an ID, means that there is no need for an
>> xmi:id in the serialization since the feature itself stores the ID
>> value. Serializing both a name and an xmi:id would be redundant.
>
>
>
> ****Arti***I agree that adding xmi:id in such a case would be redundant.
> However, in EMF's code for XMI Import, it is observed that the
> resource has two maps associated with it 1) idToObjectMap and
> 2)eObjectToIDMap
> The idToObjectMap is used while resolving references. But, this map is
> populated in resource.setID method which is invoked only when the
> idattributeName is xmi:id(or a common name at a resource level).
>
> Why isn't this map populated for any class specific id attribute. This
> would make reference resolution simpler (Because during resolution, if
> this map is null, all objects from the resource's contents are fetched
> and each object's id is checked to get the desired referenced object).
>
> reference to SAXXMLHandler code :-
>
> protected void handleObjectAttribs(EObject obj)
> {
> if (attribs != null)
> {
> InternalEObject internalEObject = (InternalEObject)obj;
> for (int i = 0, size = attribs.getLength(); i < size; ++i)
> {
> String name = attribs.getQName(i);
> if (name.equals(idAttribute))
> {
> xmlResource.setID(internalEObject, attribs.getValue(i));
> }
> ---
> ---
> ---
> }
>
>
> Ed Merks wrote:
>
>> It's hard to read your document with all the "..." in it. The fact
>> that all your IDs are not valid XML Schema IDs, i.e., non-colonized
>> names, is likely a cause of problems. The presence of a : in the ID
>> will make it look like a QName and that will mess things up.
>
>
>
> ****Arti***Thanks,I was able to import the document in EMF with valid
> IDs.
>
|
|
|
Goto Forum:
Current Time: Tue Nov 04 12:39:14 EST 2025
Powered by FUDForum. Page generated in 0.40068 seconds |
Home