Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Other model backends
Other model backends [message #56413] Thu, 22 May 2008 07:52 Go to next message
Eclipse User
Originally posted by: stepper.sympedia.de

Hi Christian,

Is it possible to use OCL with non-Ecore based models?

I ask this because Simon and I plan to develop a remote query mechanism
for CDO and a CDO repository usually doesn't know about Ecore.
Internally (over the network and in the server) CDO uses a different
concept of CDORevisions which capture a single state in the lifetime of
a client side EObject (instance level). At the model level CDO uses the
concept of a CDOClass which is contained in a CDOPackage and has
CDOFeatures. All these concepts are more or less mappeable to/from their
Ecore counter parts.

In addition it would be interesting to use OCL as a server side
validation facility. Incoming CommitTransactionRequests could be
validated remotely before being applied to a backend.

Cheers
/Eike
Re: Other model backends [message #56468 is a reply to message #56413] Thu, 22 May 2008 19:38 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

--=-tTG6FmFvt15vInZdAul0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Eike,

Yes. Since the 1.1 release, MDT OCL supports the implementation of
"metamodel bindings." Out-of-the-box, the MDT OCL SDK provides bindings
for Ecore and UML.

You need to ensure that your metamodel implements the constructs
required by OCL in some fashion: these are the notions of Classifier,
Operation, Property, etc. Your metamodel must be Ecore-based (Ecore is
the meta-metamodel). If these requirements are satisfied, you basically
provide three things:


* an EnvironmentFactory implementation (with an Environment and
UMLReflection implementation) for your metamodel
* a specialization of the AST model (the Types and Expressions
packages) that supplies the generic type parameter substitutions
that map your metamodel's constructs to OCL's parameters and
mixes in the generalizations of your metamodel's Classifier and
TypedElement constructs
* an implementation of the OCL Standard Library as an instance of
your metamodel


The Ecore and UML bindings provided by the SDK serve as examples, and
the Advanced Topics in the developer guide has a word or two to say on
the subject. I have seen evidence at EclipseCon of additional metamodel
bindings, and I have prototyped the concept with SQL, myself.

Perhaps I can contribute in some way? One tool that is lacking from the
MDT OCL SDK is the metamodel-binding generator. It's a lot of work to
build one by hand, and it could benefit a lot from some automation.

HTH,

Christian

On Thu, 2008-05-22 at 09:52 +0200, Eike Stepper wrote:

> Hi Christian,
>
> Is it possible to use OCL with non-Ecore based models?
>
> I ask this because Simon and I plan to develop a remote query mechanism
> for CDO and a CDO repository usually doesn't know about Ecore.
> Internally (over the network and in the server) CDO uses a different
> concept of CDORevisions which capture a single state in the lifetime of
> a client side EObject (instance level). At the model level CDO uses the
> concept of a CDOClass which is contained in a CDOPackage and has
> CDOFeatures. All these concepts are more or less mappeable to/from their
> Ecore counter parts.
>
> In addition it would be interesting to use OCL as a server side
> validation facility. Incoming CommitTransactionRequests could be
> validated remotely before being applied to a backend.
>
> Cheers
> /Eike
>

--=-tTG6FmFvt15vInZdAul0
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.1">
</HEAD>
<BODY>
Hi, Eike,<BR>
<BR>
Yes.&nbsp; Since the 1.1 release, MDT OCL supports the implementation of &quot;metamodel bindings.&quot;&nbsp; Out-of-the-box, the MDT OCL SDK provides bindings for Ecore and UML.<BR>
<BR>
You need to ensure that your metamodel implements the constructs required by OCL in some fashion:&nbsp; these are the notions of Classifier, Operation, Property, etc.&nbsp; Your metamodel must be Ecore-based (Ecore is the meta-metamodel).&nbsp; If these requirements are satisfied, you basically provide three things:<BR>
<BR>
<UL>
<LI>an EnvironmentFactory implementation (with an Environment and UMLReflection implementation) for your metamodel
<LI>a specialization of the AST model (the Types and Expressions packages) that supplies the generic type parameter substitutions that map your metamodel's constructs to OCL's parameters and mixes in the generalizations of your metamodel's Classifier and TypedElement constructs
<LI>an implementation of the OCL Standard Library as an instance of your metamodel
</UL>
<BR>
The Ecore and UML bindings provided by the SDK serve as examples, and the Advanced Topics in the developer guide has a word or two to say on the subject.&nbsp; I have seen evidence at EclipseCon of additional metamodel bindings, and I have prototyped the concept with SQL, myself.<BR>
<BR>
Perhaps I can contribute in some way?&nbsp; One tool that is lacking from the MDT OCL SDK is the metamodel-binding generator.&nbsp; It's a lot of work to build one by hand, and it could benefit a lot from some automation.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
On Thu, 2008-05-22 at 09:52 +0200, Eike Stepper wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Hi Christian,</FONT>

<FONT COLOR="#000000">Is it possible to use OCL with non-Ecore based models?</FONT>

<FONT COLOR="#000000">I ask this because Simon and I plan to develop a remote query mechanism </FONT>
<FONT COLOR="#000000">for CDO and a CDO repository usually doesn't know about Ecore. </FONT>
<FONT COLOR="#000000">Internally (over the network and in the server) CDO uses a different </FONT>
<FONT COLOR="#000000">concept of CDORevisions which capture a single state in the lifetime of </FONT>
<FONT COLOR="#000000">a client side EObject (instance level). At the model level CDO uses the </FONT>
<FONT COLOR="#000000">concept of a CDOClass which is contained in a CDOPackage and has </FONT>
<FONT COLOR="#000000">CDOFeatures. All these concepts are more or less mappeable to/from their </FONT>
<FONT COLOR="#000000">Ecore counter parts.</FONT>

<FONT COLOR="#000000">In addition it would be interesting to use OCL as a server side </FONT>
<FONT COLOR="#000000">validation facility. Incoming CommitTransactionRequests could be </FONT>
<FONT COLOR="#000000">validated remotely before being applied to a backend.</FONT>

<FONT COLOR="#000000">Cheers</FONT>
<FONT COLOR="#000000">/Eike</FONT>

</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-tTG6FmFvt15vInZdAul0--
Re: Other model backends [message #56521 is a reply to message #56468] Fri, 23 May 2008 06:08 Go to previous messageGo to next message
Eclipse User
Originally posted by: stepper.sympedia.de

Hi Christian,

Thanks for the info. It sounds promising on one hand and on the other
I'm a bit worried about your statement concerning the meta-meta-model
requirement (Ecore). Since we have no explicit models at all I'd like to
explain it in Java terms:

From an API perspective in a CDO client we have real EObjects in
memory. In fact they're typed CDOObject which extends EObject:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=marku p

From an implementation point of view the main difference between
EObjectImpl and CDOObjectImpl is that the latter does not store the
modeled state in Java instance fields but instead somewhere in the
associated CDORevision:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup

Reflectively accessible via CDORevisionData:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup

These CDORevisions are transferred over the network and stored somehow
in the CDO server. Notice that there is no dependenciy from CDORevision
on Ecore at all! A CDORevision is associated with a CDOClass which also
relates to an EClass but only in a sematical sense. There's no
dependency from CDOClass on Ecore. In general, everything in CDO that
passes the network is implemented in the cdo.protocol plugin which has,
again, no dependency on EMF/Ecore.

This is the situation: At the CDO server side we have no EMF, thus no
Ecore. But we have instances that support reflective access via a
dynamic model that semantically relates to an Ecore model. Btw. a
CDOClass looks like:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup

Sorry for the lengthy monologue ;-)

What makes me a bit more hopeful is your statement about SQL below
which, in itself, is not Ecore derived. Or do you mean something like an
SQL.ecore?

Anyway, I suspect that you get an impression of the situation in a CDO
server. Do you think it's worth discussing whether/how your OCL
interpreter is able to validate CDORevision instances?

And yes, if it'd be possible somehow, your contribution would be
welcome! ;-)

Cheers
/Eike

p.s. Will you be coming to ESE? Ed mentioned a modeling symposium a day
in advance...


Christian W. Damus schrieb:
> Hi, Eike,
>
> Yes. Since the 1.1 release, MDT OCL supports the implementation of
> "metamodel bindings." Out-of-the-box, the MDT OCL SDK provides
> bindings for Ecore and UML.
>
> You need to ensure that your metamodel implements the constructs
> required by OCL in some fashion: these are the notions of Classifier,
> Operation, Property, etc. Your metamodel must be Ecore-based (Ecore
> is the meta-metamodel). If these requirements are satisfied, you
> basically provide three things:
>
> * an EnvironmentFactory implementation (with an Environment and
> UMLReflection implementation) for your metamodel
> * a specialization of the AST model (the Types and Expressions
> packages) that supplies the generic type parameter substitutions
> that map your metamodel's constructs to OCL's parameters and
> mixes in the generalizations of your metamodel's Classifier and
> TypedElement constructs
> * an implementation of the OCL Standard Library as an instance of
> your metamodel
>
>
> The Ecore and UML bindings provided by the SDK serve as examples, and
> the Advanced Topics in the developer guide has a word or two to say on
> the subject. I have seen evidence at EclipseCon of additional
> metamodel bindings, and I have prototyped the concept with SQL, myself.
>
> Perhaps I can contribute in some way? One tool that is lacking from
> the MDT OCL SDK is the metamodel-binding generator. It's a lot of
> work to build one by hand, and it could benefit a lot from some
> automation.
>
> HTH,
>
> Christian
>
> On Thu, 2008-05-22 at 09:52 +0200, Eike Stepper wrote:
>> Hi Christian,
>>
>> Is it possible to use OCL with non-Ecore based models?
>>
>> I ask this because Simon and I plan to develop a remote query mechanism
>> for CDO and a CDO repository usually doesn't know about Ecore.
>> Internally (over the network and in the server) CDO uses a different
>> concept of CDORevisions which capture a single state in the lifetime of
>> a client side EObject (instance level). At the model level CDO uses the
>> concept of a CDOClass which is contained in a CDOPackage and has
>> CDOFeatures. All these concepts are more or less mappeable to/from their
>> Ecore counter parts.
>>
>> In addition it would be interesting to use OCL as a server side
>> validation facility. Incoming CommitTransactionRequests could be
>> validated remotely before being applied to a backend.
>>
>> Cheers
>> /Eike
>>
>>
Re: Other model backends [message #56924 is a reply to message #56521] Wed, 28 May 2008 01:49 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

--=-2LAU8m9wLgxbdo5uatFO
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Eike,

Sorry for the delayed response. See some replies in-line.

cW


On Fri, 2008-05-23 at 08:08 +0200, Eike Stepper wrote:

> Hi Christian,
>
> Thanks for the info. It sounds promising on one hand and on the other
> I'm a bit worried about your statement concerning the meta-meta-model
> requirement (Ecore). Since we have no explicit models at all I'd like to
> explain it in Java terms:


Well, the OCL Abstract Syntax Model needs to be able to reference model
elements, and to persist those references via the usual EMF mechanisms.
That implied a requirement that the target metamodel be EMF-based.



> From an API perspective in a CDO client we have real EObjects in
> memory. In fact they're typed CDOObject which extends EObject:
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=marku p
>
> From an implementation point of view the main difference between
> EObjectImpl and CDOObjectImpl is that the latter does not store the
> modeled state in Java instance fields but instead somewhere in the
> associated CDORevision:
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup
>
> Reflectively accessible via CDORevisionData:
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup
>
> These CDORevisions are transferred over the network and stored somehow
> in the CDO server. Notice that there is no dependenciy from CDORevision
> on Ecore at all! A CDORevision is associated with a CDOClass which also
> relates to an EClass but only in a sematical sense. There's no
> dependency from CDOClass on Ecore. In general, everything in CDO that
> passes the network is implemented in the cdo.protocol plugin which has,
> again, no dependency on EMF/Ecore.

If you have CDOClasses paired with EClasses, then perhaps for OCL
purposes you could implement this mapping on-the-fly? The Environment
and EvaluationEnvironment APIs should be sufficiently abstract to allow
you to delegate the EMF-based access to the CDOClasses and
CDORevisions ... at least, if you can't, then perhaps this API needs
enhancement.




> This is the situation: At the CDO server side we have no EMF, thus no
> Ecore. But we have instances that support reflective access via a
> dynamic model that semantically relates to an Ecore model. Btw. a
> CDOClass looks like:
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup
>
> Sorry for the lengthy monologue ;-)
>
> What makes me a bit more hopeful is your statement about SQL below
> which, in itself, is not Ecore derived. Or do you mean something like an
> SQL.ecore?



That's what I meant. In fact, the SQL metamodel from DTP.



> Anyway, I suspect that you get an impression of the situation in a CDO
> server. Do you think it's worth discussing whether/how your OCL
> interpreter is able to validate CDORevision instances?


Yes, it would make a good case study for the generality of the
metamodel-binding mechanism.



> And yes, if it'd be possible somehow, your contribution would be
> welcome! ;-)


Heh heh ... that's the trick, isn't it? Finding the opportunity to do
yet more work! :-P



>
> Cheers
> /Eike
>
> p.s. Will you be coming to ESE? Ed mentioned a modeling symposium a day
> in advance...
>
>
> Christian W. Damus schrieb:
> > Hi, Eike,
> >
> > Yes. Since the 1.1 release, MDT OCL supports the implementation of
> > "metamodel bindings." Out-of-the-box, the MDT OCL SDK provides
> > bindings for Ecore and UML.
> >
> > You need to ensure that your metamodel implements the constructs
> > required by OCL in some fashion: these are the notions of Classifier,
> > Operation, Property, etc. Your metamodel must be Ecore-based (Ecore
> > is the meta-metamodel). If these requirements are satisfied, you
> > basically provide three things:
> >
> > * an EnvironmentFactory implementation (with an Environment and
> > UMLReflection implementation) for your metamodel
> > * a specialization of the AST model (the Types and Expressions
> > packages) that supplies the generic type parameter substitutions
> > that map your metamodel's constructs to OCL's parameters and
> > mixes in the generalizations of your metamodel's Classifier and
> > TypedElement constructs
> > * an implementation of the OCL Standard Library as an instance of
> > your metamodel
> >
> >
> > The Ecore and UML bindings provided by the SDK serve as examples, and
> > the Advanced Topics in the developer guide has a word or two to say on
> > the subject. I have seen evidence at EclipseCon of additional
> > metamodel bindings, and I have prototyped the concept with SQL, myself.
> >
> > Perhaps I can contribute in some way? One tool that is lacking from
> > the MDT OCL SDK is the metamodel-binding generator. It's a lot of
> > work to build one by hand, and it could benefit a lot from some
> > automation.
> >
> > HTH,
> >
> > Christian
> >
> > On Thu, 2008-05-22 at 09:52 +0200, Eike Stepper wrote:
> >> Hi Christian,
> >>
> >> Is it possible to use OCL with non-Ecore based models?
> >>
> >> I ask this because Simon and I plan to develop a remote query mechanism
> >> for CDO and a CDO repository usually doesn't know about Ecore.
> >> Internally (over the network and in the server) CDO uses a different
> >> concept of CDORevisions which capture a single state in the lifetime of
> >> a client side EObject (instance level). At the model level CDO uses the
> >> concept of a CDOClass which is contained in a CDOPackage and has
> >> CDOFeatures. All these concepts are more or less mappeable to/from their
> >> Ecore counter parts.
> >>
> >> In addition it would be interesting to use OCL as a server side
> >> validation facility. Incoming CommitTransactionRequests could be
> >> validated remotely before being applied to a backend.
> >>
> >> Cheers
> >> /Eike
> >>
> >>

--=-2LAU8m9wLgxbdo5uatFO
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Eike,<BR>
<BR>
Sorry for the delayed response.&nbsp; See some replies in-line.<BR>
<BR>
cW<BR>
<BR>
<BR>
On Fri, 2008-05-23 at 08:08 +0200, Eike Stepper wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Hi Christian,</FONT>

<FONT COLOR="#000000">Thanks for the info. It sounds promising on one hand and on the other </FONT>
<FONT COLOR="#000000">I'm a bit worried about your statement concerning the meta-meta-model </FONT>
<FONT COLOR="#000000">requirement (Ecore). Since we have no explicit models at all I'd like to </FONT>
<FONT COLOR="#000000">explain it in Java terms:</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
Well, the OCL Abstract Syntax Model needs to be able to reference model elements, and to persist those references via the usual EMF mechanisms.&nbsp; That implied a requirement that the target metamodel be EMF-based.<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000"> From an API perspective in a CDO client we have real EObjects in </FONT>
<FONT COLOR="#000000">memory. In fact they're typed CDOObject which extends EObject: </FONT>
<FONT COLOR="#000000"><A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=marku p"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&amp;view=markup</A></FONT>

<FONT COLOR="#000000"> From an implementation point of view the main difference between </FONT>
<FONT COLOR="#000000">EObjectImpl and CDOObjectImpl is that the latter does not store the </FONT>
<FONT COLOR="#000000">modeled state in Java instance fields but instead somewhere in the </FONT>
<FONT COLOR="#000000">associated CDORevision: </FONT>
<FONT COLOR="#000000"><A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&amp;view=markup</A></FONT>

<FONT COLOR="#000000">Reflectively accessible via CDORevisionData: </FONT>
<FONT COLOR="#000000"><A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&amp;view=markup</A></FONT>

<FONT COLOR="#000000">These CDORevisions are transferred over the network and stored somehow </FONT>
<FONT COLOR="#000000">in the CDO server. Notice that there is no dependenciy from CDORevision </FONT>
<FONT COLOR="#000000">on Ecore at all! A CDORevision is associated with a CDOClass which also </FONT>
<FONT COLOR="#000000">relates to an EClass but only in a sematical sense. There's no </FONT>
<FONT COLOR="#000000">dependency from CDOClass on Ecore. In general, everything in CDO that </FONT>
<FONT COLOR="#000000">passes the network is implemented in the cdo.protocol plugin which has, </FONT>
<FONT COLOR="#000000">again, no dependency on EMF/Ecore.</FONT>
</PRE>
</BLOCKQUOTE>
If you have CDOClasses paired with EClasses, then perhaps for OCL purposes you could implement this mapping on-the-fly?&nbsp; The Environment and EvaluationEnvironment APIs should be sufficiently abstract to allow you to delegate the EMF-based access to the CDOClasses and CDORevisions ... at least, if you can't, then perhaps this API needs enhancement.<BR>
<BR>
<PRE>

</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">This is the situation: At the CDO server side we have no EMF, thus no </FONT>
<FONT COLOR="#000000">Ecore. But we have instances that support reflective access via a </FONT>
<FONT COLOR="#000000">dynamic model that semantically relates to an Ecore model. Btw. a </FONT>
<FONT COLOR="#000000">CDOClass looks like: </FONT>
<FONT COLOR="#000000"><A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&amp;view=markup</A></FONT>

<FONT COLOR="#000000">Sorry for the lengthy monologue ;-)</FONT>

<FONT COLOR="#000000">What makes me a bit more hopeful is your statement about SQL below </FONT>
<FONT COLOR="#000000">which, in itself, is not Ecore derived. Or do you mean something like an </FONT>
<FONT COLOR="#000000">SQL.ecore?</FONT>
</PRE>
</BLOCKQUOTE>
<PRE>

</PRE>
That's what I meant.&nbsp; In fact, the SQL metamodel from DTP.<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Anyway, I suspect that you get an impression of the situation in a CDO </FONT>
<FONT COLOR="#000000">server. Do you think it's worth discussing whether/how your OCL </FONT>
<FONT COLOR="#000000">interpreter is able to validate CDORevision instances?</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
Yes, it would make a good case study for the generality of the metamodel-binding mechanism.
<PRE>

</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">And yes, if it'd be possible somehow, your contribution would be </FONT>
<FONT COLOR="#000000">welcome! ;-)</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
Heh heh ... that's the trick, isn't it?&nbsp; Finding the opportunity to do yet more work!&nbsp; :-P<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>

<FONT COLOR="#000000">Cheers</FONT>
<FONT COLOR="#000000">/Eike</FONT>

<FONT COLOR="#000000">p.s. Will you be coming to ESE? Ed mentioned a modeling symposium a day </FONT>
<FONT COLOR="#000000">in advance...</FONT>


<FONT COLOR="#000000">Christian W. Damus schrieb:</FONT>
<FONT COLOR="#000000">&gt; Hi, Eike,</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt; Yes. Since the 1.1 release, MDT OCL supports the implementation of </FONT>
<FONT COLOR="#000000">&gt; &quot;metamodel bindings.&quot; Out-of-the-box, the MDT OCL SDK provides </FONT>
<FONT COLOR="#000000">&gt; bindings for Ecore and UML.</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt; You need to ensure that your metamodel implements the constructs </FONT>
<FONT COLOR="#000000">&gt; required by OCL in some fashion: these are the notions of Classifier, </FONT>
<FONT COLOR="#000000">&gt; Operation, Property, etc. Your metamodel must be Ecore-based (Ecore </FONT>
<FONT COLOR="#000000">&gt; is the meta-metamodel). If these requirements are satisfied, you </FONT>
<FONT COLOR="#000000">&gt; basically provide three things:</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt; * an EnvironmentFactory implementation (with an Environment and</FONT>
<FONT COLOR="#000000">&gt; UMLReflection implementation) for your metamodel</FONT>
<FONT COLOR="#000000">&gt; * a specialization of the AST model (the Types and Expressions</FONT>
<FONT COLOR="#000000">&gt; packages) that supplies the generic type parameter substitutions</FONT>
<FONT COLOR="#000000">&gt; that map your metamodel's constructs to OCL's parameters and</FONT>
<FONT COLOR="#000000">&gt; mixes in the generalizations of your metamodel's Classifier and</FONT>
<FONT COLOR="#000000">&gt; TypedElement constructs</FONT>
<FONT COLOR="#000000">&gt; * an implementation of the OCL Standard Library as an instance of</FONT>
<FONT COLOR="#000000">&gt; your metamodel</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt; The Ecore and UML bindings provided by the SDK serve as examples, and </FONT>
<FONT COLOR="#000000">&gt; the Advanced Topics in the developer guide has a word or two to say on </FONT>
<FONT COLOR="#000000">&gt; the subject. I have seen evidence at EclipseCon of additional </FONT>
<FONT COLOR="#000000">&gt; metamodel bindings, and I have prototyped the concept with SQL, myself.</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt; Perhaps I can contribute in some way? One tool that is lacking from </FONT>
<FONT COLOR="#000000">&gt; the MDT OCL SDK is the metamodel-binding generator. It's a lot of </FONT>
<FONT COLOR="#000000">&gt; work to build one by hand, and it could benefit a lot from some </FONT>
<FONT COLOR="#000000">&gt; automation.</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt; HTH,</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt; Christian</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt; On Thu, 2008-05-22 at 09:52 +0200, Eike Stepper wrote:</FONT>
<FONT COLOR="#000000">&gt;&gt; Hi Christian,</FONT>
<FONT COLOR="#000000">&gt;&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; Is it possible to use OCL with non-Ecore based models?</FONT>
<FONT COLOR="#000000">&gt;&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; I ask this because Simon and I plan to develop a remote query mechanism </FONT>
<FONT COLOR="#000000">&gt;&gt; for CDO and a CDO repository usually doesn't know about Ecore. </FONT>
<FONT COLOR="#000000">&gt;&gt; Internally (over the network and in the server) CDO uses a different </FONT>
<FONT COLOR="#000000">&gt;&gt; concept of CDORevisions which capture a single state in the lifetime of </FONT>
<FONT COLOR="#000000">&gt;&gt; a client side EObject (instance level). At the model level CDO uses the </FONT>
<FONT COLOR="#000000">&gt;&gt; concept of a CDOClass which is contained in a CDOPackage and has </FONT>
<FONT COLOR="#000000">&gt;&gt; CDOFeatures. All these concepts are more or less mappeable to/from their </FONT>
<FONT COLOR="#000000">&gt;&gt; Ecore counter parts.</FONT>
<FONT COLOR="#000000">&gt;&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; In addition it would be interesting to use OCL as a server side </FONT>
<FONT COLOR="#000000">&gt;&gt; validation facility. Incoming CommitTransactionRequests could be </FONT>
<FONT COLOR="#000000">&gt;&gt; validated remotely before being applied to a backend.</FONT>
<FONT COLOR="#000000">&gt;&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; Cheers</FONT>
<FONT COLOR="#000000">&gt;&gt; /Eike</FONT>
<FONT COLOR="#000000">&gt;&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; </FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-2LAU8m9wLgxbdo5uatFO--
Re: Other model backends [message #56950 is a reply to message #56924] Wed, 28 May 2008 06:41 Go to previous messageGo to next message
Eclipse User
Originally posted by: stepper.sympedia.de

Hi Christian,

I hoped that your OCL interpreter has a similar model interface like the
Dresden OCL Toolkit: http://dresden-ocl.sourceforge.net
It's long ago that I played with it, but they have sort of an abstract
model facade that is independent on concreate model implementations
(like EMF). For several such implementations they have bridges (EMF,
MDR). With such a design it would be comparingly easy to develop a new
model bridge.

Btw. this sounds interesting, too:
http://dresden-ocl.sourceforge.net/gbbraeuer/index.html

I cc'ed Simon because he'll do the main work to integrate the CDO server
with OCL.
And yes, my participation offer is a bit plump -- but you asked ;-)

Btw2. I still plan to work with you on the incremental validation stuff
that we talked about last Con.
Or is your ability to spend unpaid effort more limited with your new job?

Cheers
/Eike



Christian W. Damus schrieb:
> Hi, Eike,
>
> Sorry for the delayed response. See some replies in-line.
>
> cW
>
>
> On Fri, 2008-05-23 at 08:08 +0200, Eike Stepper wrote:
>> Hi Christian,
>>
>> Thanks for the info. It sounds promising on one hand and on the other
>> I'm a bit worried about your statement concerning the meta-meta-model
>> requirement (Ecore). Since we have no explicit models at all I'd like to
>> explain it in Java terms:
>>
>
> Well, the OCL Abstract Syntax Model needs to be able to reference
> model elements, and to persist those references via the usual EMF
> mechanisms. That implied a requirement that the target metamodel be
> EMF-based.
>
>
>> From an API perspective in a CDO client we have real EObjects in
>> memory. In fact they're typed CDOObject which extends EObject:
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=marku p < http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=marku p>
>>
>> From an implementation point of view the main difference between
>> EObjectImpl and CDOObjectImpl is that the latter does not store the
>> modeled state in Java instance fields but instead somewhere in the
>> associated CDORevision:
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup < http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup>
>>
>> Reflectively accessible via CDORevisionData:
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup < http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup>
>>
>> These CDORevisions are transferred over the network and stored somehow
>> in the CDO server. Notice that there is no dependenciy from CDORevision
>> on Ecore at all! A CDORevision is associated with a CDOClass which also
>> relates to an EClass but only in a sematical sense. There's no
>> dependency from CDOClass on Ecore. In general, everything in CDO that
>> passes the network is implemented in the cdo.protocol plugin which has,
>> again, no dependency on EMF/Ecore.
>>
> If you have CDOClasses paired with EClasses, then perhaps for OCL
> purposes you could implement this mapping on-the-fly? The Environment
> and EvaluationEnvironment APIs should be sufficiently abstract to
> allow you to delegate the EMF-based access to the CDOClasses and
> CDORevisions ... at least, if you can't, then perhaps this API needs
> enhancement.
>
>
>> This is the situation: At the CDO server side we have no EMF, thus no
>> Ecore. But we have instances that support reflective access via a
>> dynamic model that semantically relates to an Ecore model. Btw. a
>> CDOClass looks like:
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup < http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup>
>>
>> Sorry for the lengthy monologue ;-)
>>
>> What makes me a bit more hopeful is your statement about SQL below
>> which, in itself, is not Ecore derived. Or do you mean something like an
>> SQL.ecore?
>>
>
> That's what I meant. In fact, the SQL metamodel from DTP.
>
>
>> Anyway, I suspect that you get an impression of the situation in a CDO
>> server. Do you think it's worth discussing whether/how your OCL
>> interpreter is able to validate CDORevision instances?
>>
>
> Yes, it would make a good case study for the generality of the
> metamodel-binding mechanism.
>
>> And yes, if it'd be possible somehow, your contribution would be
>> welcome! ;-)
>>
>
> Heh heh ... that's the trick, isn't it? Finding the opportunity to do
> yet more work! :-P
>
>
>> Cheers
>> /Eike
>>
>> p.s. Will you be coming to ESE? Ed mentioned a modeling symposium a day
>> in advance...
>>
>>
>> Christian W. Damus schrieb:
>> > Hi, Eike,
>> >
>> > Yes. Since the 1.1 release, MDT OCL supports the implementation of
>> > "metamodel bindings." Out-of-the-box, the MDT OCL SDK provides
>> > bindings for Ecore and UML.
>> >
>> > You need to ensure that your metamodel implements the constructs
>> > required by OCL in some fashion: these are the notions of Classifier,
>> > Operation, Property, etc. Your metamodel must be Ecore-based (Ecore
>> > is the meta-metamodel). If these requirements are satisfied, you
>> > basically provide three things:
>> >
>> > * an EnvironmentFactory implementation (with an Environment and
>> > UMLReflection implementation) for your metamodel
>> > * a specialization of the AST model (the Types and Expressions
>> > packages) that supplies the generic type parameter substitutions
>> > that map your metamodel's constructs to OCL's parameters and
>> > mixes in the generalizations of your metamodel's Classifier and
>> > TypedElement constructs
>> > * an implementation of the OCL Standard Library as an instance of
>> > your metamodel
>> >
>> >
>> > The Ecore and UML bindings provided by the SDK serve as examples, and
>> > the Advanced Topics in the developer guide has a word or two to say on
>> > the subject. I have seen evidence at EclipseCon of additional
>> > metamodel bindings, and I have prototyped the concept with SQL, myself.
>> >
>> > Perhaps I can contribute in some way? One tool that is lacking from
>> > the MDT OCL SDK is the metamodel-binding generator. It's a lot of
>> > work to build one by hand, and it could benefit a lot from some
>> > automation.
>> >
>> > HTH,
>> >
>> > Christian
>> >
>> > On Thu, 2008-05-22 at 09:52 +0200, Eike Stepper wrote:
>> >> Hi Christian,
>> >>
>> >> Is it possible to use OCL with non-Ecore based models?
>> >>
>> >> I ask this because Simon and I plan to develop a remote query mechanism
>> >> for CDO and a CDO repository usually doesn't know about Ecore.
>> >> Internally (over the network and in the server) CDO uses a different
>> >> concept of CDORevisions which capture a single state in the lifetime of
>> >> a client side EObject (instance level). At the model level CDO uses the
>> >> concept of a CDOClass which is contained in a CDOPackage and has
>> >> CDOFeatures. All these concepts are more or less mappeable to/from their
>> >> Ecore counter parts.
>> >>
>> >> In addition it would be interesting to use OCL as a server side
>> >> validation facility. Incoming CommitTransactionRequests could be
>> >> validated remotely before being applied to a backend.
>> >>
>> >> Cheers
>> >> /Eike
>> >>
>> >>
>>
Re: Other model backends [message #57349 is a reply to message #56950] Fri, 30 May 2008 03:31 Go to previous message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

--=-S03OkZHhym7xySay1BH2
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Eike,

See some replies, in-line.

cW


On Wed, 2008-05-28 at 08:41 +0200, Eike Stepper wrote:

> Hi Christian,
>
> I hoped that your OCL interpreter has a similar model interface like the
> Dresden OCL Toolkit: http://dresden-ocl.sourceforge.net


Yeah. That never was a design priority for the OCL component, since way
back in the days when it live in IBM RSA (before it was contributed to
Eclipse). It was always intended to be EMF-based, and there didn't seem
much reason to change that in the Eclipse Modeling Project.

If there really is sufficient interest in opening up the design beyond
EMF, then of course we might entertain the idea.



> It's long ago that I played with it, but they have sort of an abstract
> model facade that is independent on concreate model implementations
> (like EMF). For several such implementations they have bridges (EMF,
> MDR). With such a design it would be comparingly easy to develop a new
> model bridge.


Yes, that is a common pattern in OCL implementations.





> Btw. this sounds interesting, too:
> http://dresden-ocl.sourceforge.net/gbbraeuer/index.html
>
> I cc'ed Simon because he'll do the main work to integrate the CDO server
> with OCL.
> And yes, my participation offer is a bit plump -- but you asked ;-)


Plump? Perhaps you are translating a German idiom too
literally ... :-)




> Btw2. I still plan to work with you on the incremental validation stuff
> that we talked about last Con.
> Or is your ability to spend unpaid effort more limited with your new job?


I'm still interested in this, of course, because I think there is
potential for some valuable new work in the OCL component. Any time
that I spend on it will mostly be my own, but it will be fun. And I'll
be very happy to see you and Simon join the OCL contributor community,
which I hope to do a better job of fostering in the next release. We
should starting hatching plan items in this area for the 1.3 release
after Ganymede.


>
> Cheers
> /Eike
>
>
>
> Christian W. Damus schrieb:
> > Hi, Eike,
> >
> > Sorry for the delayed response. See some replies in-line.
> >
> > cW
> >
> >
> > On Fri, 2008-05-23 at 08:08 +0200, Eike Stepper wrote:
> >> Hi Christian,
> >>
> >> Thanks for the info. It sounds promising on one hand and on the other
> >> I'm a bit worried about your statement concerning the meta-meta-model
> >> requirement (Ecore). Since we have no explicit models at all I'd like to
> >> explain it in Java terms:
> >>
> >
> > Well, the OCL Abstract Syntax Model needs to be able to reference
> > model elements, and to persist those references via the usual EMF
> > mechanisms. That implied a requirement that the target metamodel be
> > EMF-based.
> >
> >
> >> From an API perspective in a CDO client we have real EObjects in
> >> memory. In fact they're typed CDOObject which extends EObject:
> >> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=marku p < http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=marku p>
> >>
> >> From an implementation point of view the main difference between
> >> EObjectImpl and CDOObjectImpl is that the latter does not store the
> >> modeled state in Java instance fields but instead somewhere in the
> >> associated CDORevision:
> >> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup < http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup>
> >>
> >> Reflectively accessible via CDORevisionData:
> >> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup < http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup>
> >>
> >> These CDORevisions are transferred over the network and stored somehow
> >> in the CDO server. Notice that there is no dependenciy from CDORevision
> >> on Ecore at all! A CDORevision is associated with a CDOClass which also
> >> relates to an EClass but only in a sematical sense. There's no
> >> dependency from CDOClass on Ecore. In general, everything in CDO that
> >> passes the network is implemented in the cdo.protocol plugin which has,
> >> again, no dependency on EMF/Ecore.
> >>
> > If you have CDOClasses paired with EClasses, then perhaps for OCL
> > purposes you could implement this mapping on-the-fly? The Environment
> > and EvaluationEnvironment APIs should be sufficiently abstract to
> > allow you to delegate the EMF-based access to the CDOClasses and
> > CDORevisions ... at least, if you can't, then perhaps this API needs
> > enhancement.
> >
> >
> >> This is the situation: At the CDO server side we have no EMF, thus no
> >> Ecore. But we have instances that support reflective access via a
> >> dynamic model that semantically relates to an Ecore model. Btw. a
> >> CDOClass looks like:
> >> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup < http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup>
> >>
> >> Sorry for the lengthy monologue ;-)
> >>
> >> What makes me a bit more hopeful is your statement about SQL below
> >> which, in itself, is not Ecore derived. Or do you mean something like an
> >> SQL.ecore?
> >>
> >
> > That's what I meant. In fact, the SQL metamodel from DTP.
> >
> >
> >> Anyway, I suspect that you get an impression of the situation in a CDO
> >> server. Do you think it's worth discussing whether/how your OCL
> >> interpreter is able to validate CDORevision instances?
> >>
> >
> > Yes, it would make a good case study for the generality of the
> > metamodel-binding mechanism.
> >
> >> And yes, if it'd be possible somehow, your contribution would be
> >> welcome! ;-)
> >>
> >
> > Heh heh ... that's the trick, isn't it? Finding the opportunity to do
> > yet more work! :-P
> >
> >
> >> Cheers
> >> /Eike
> >>
> >> p.s. Will you be coming to ESE? Ed mentioned a modeling symposium a day
> >> in advance...
> >>
> >>
> >> Christian W. Damus schrieb:
> >> > Hi, Eike,
> >> >
> >> > Yes. Since the 1.1 release, MDT OCL supports the implementation of
> >> > "metamodel bindings." Out-of-the-box, the MDT OCL SDK provides
> >> > bindings for Ecore and UML.
> >> >
> >> > You need to ensure that your metamodel implements the constructs
> >> > required by OCL in some fashion: these are the notions of Classifier,
> >> > Operation, Property, etc. Your metamodel must be Ecore-based (Ecore
> >> > is the meta-metamodel). If these requirements are satisfied, you
> >> > basically provide three things:
> >> >
> >> > * an EnvironmentFactory implementation (with an Environment and
> >> > UMLReflection implementation) for your metamodel
> >> > * a specialization of the AST model (the Types and Expressions
> >> > packages) that supplies the generic type parameter substitutions
> >> > that map your metamodel's constructs to OCL's parameters and
> >> > mixes in the generalizations of your metamodel's Classifier and
> >> > TypedElement constructs
> >> > * an implementation of the OCL Standard Library as an instance of
> >> > your metamodel
> >> >
> >> >
> >> > The Ecore and UML bindings provided by the SDK serve as examples, and
> >> > the Advanced Topics in the developer guide has a word or two to say on
> >> > the subject. I have seen evidence at EclipseCon of additional
> >> > metamodel bindings, and I have prototyped the concept with SQL, myself.
> >> >
> >> > Perhaps I can contribute in some way? One tool that is lacking from
> >> > the MDT OCL SDK is the metamodel-binding generator. It's a lot of
> >> > work to build one by hand, and it could benefit a lot from some
> >> > automation.
> >> >
> >> > HTH,
> >> >
> >> > Christian
> >> >
> >> > On Thu, 2008-05-22 at 09:52 +0200, Eike Stepper wrote:
> >> >> Hi Christian,
> >> >>
> >> >> Is it possible to use OCL with non-Ecore based models?
> >> >>
> >> >> I ask this because Simon and I plan to develop a remote query mechanism
> >> >> for CDO and a CDO repository usually doesn't know about Ecore.
> >> >> Internally (over the network and in the server) CDO uses a different
> >> >> concept of CDORevisions which capture a single state in the lifetime of
> >> >> a client side EObject (instance level). At the model level CDO uses the
> >> >> concept of a CDOClass which is contained in a CDOPackage and has
> >> >> CDOFeatures. All these concepts are more or less mappeable to/from their
> >> >> Ecore counter parts.
> >> >>
> >> >> In addition it would be interesting to use OCL as a server side
> >> >> validation facility. Incoming CommitTransactionRequests could be
> >> >> validated remotely before being applied to a backend.
> >> >>
> >> >> Cheers
> >> >> /Eike
> >> >>
> >> >>
> >>

--=-S03OkZHhym7xySay1BH2
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Eike,<BR>
<BR>
See some replies, in-line.<BR>
<BR>
cW<BR>
<BR>
<BR>
On Wed, 2008-05-28 at 08:41 +0200, Eike Stepper wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Hi Christian,</FONT>

<FONT COLOR="#000000">I hoped that your OCL interpreter has a similar model interface like the </FONT>
<FONT COLOR="#000000">Dresden OCL Toolkit: <A HREF="http://dresden-ocl.sourceforge.net">http://dresden-ocl.sourceforge.net</A></FONT>
</PRE>
</BLOCKQUOTE>
<BR>
Yeah.&nbsp; That never was a design priority for the OCL component, since way back in the days when it live in IBM RSA (before it was contributed to Eclipse).&nbsp; It was always intended to be EMF-based, and there didn't seem much reason to change that in the Eclipse Modeling Project.<BR>
<BR>
If there really is sufficient interest in opening up the design beyond EMF, then of course we might entertain the idea.<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">It's long ago that I played with it, but they have sort of an abstract </FONT>
<FONT COLOR="#000000">model facade that is independent on concreate model implementations </FONT>
<FONT COLOR="#000000">(like EMF). For several such implementations they have bridges (EMF, </FONT>
<FONT COLOR="#000000">MDR). With such a design it would be comparingly easy to develop a new </FONT>
<FONT COLOR="#000000">model bridge.</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
Yes, that is a common pattern in OCL implementations.
<PRE>

</PRE>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Btw. this sounds interesting, too: </FONT>
<FONT COLOR="#000000"><A HREF="http://dresden-ocl.sourceforge.net/gbbraeuer/index.html">http://dresden-ocl.sourceforge.net/gbbraeuer/index.html</A></FONT>

<FONT COLOR="#000000">I cc'ed Simon because he'll do the main work to integrate the CDO server </FONT>
<FONT COLOR="#000000">with OCL.</FONT>
<FONT COLOR="#000000">And yes, my participation offer is a bit plump -- but you asked ;-)</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
Plump?&nbsp; Perhaps you are translating a German idiom too literally ...&nbsp; :-)<BR>
<BR>
<PRE>

</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Btw2. I still plan to work with you on the incremental validation stuff </FONT>
<FONT COLOR="#000000">that we talked about last Con.</FONT>
<FONT COLOR="#000000">Or is your ability to spend unpaid effort more limited with your new job?</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
I'm still interested in this, of course, because I think there is potential for some valuable new work in the OCL component.&nbsp; Any time that I spend on it will mostly be my own, but it will be fun.&nbsp; And I'll be very happy to see you and Simon join the OCL contributor community, which I hope to do a better job of fostering in the next release.&nbsp; We should starting hatching plan items in this area for the 1.3 release after Ganymede.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>

<FONT COLOR="#000000">Cheers</FONT>
<FONT COLOR="#000000">/Eike</FONT>



<FONT COLOR="#000000">Christian W. Damus schrieb:</FONT>
<FONT COLOR="#000000">&gt; Hi, Eike,</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt; Sorry for the delayed response. See some replies in-line.</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt; cW</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt; On Fri, 2008-05-23 at 08:08 +0200, Eike Stepper wrote:</FONT>
<FONT COLOR="#000000">&gt;&gt; Hi Christian,</FONT>
<FONT COLOR="#000000">&gt;&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; Thanks for the info. It sounds promising on one hand and on the other </FONT>
<FONT COLOR="#000000">&gt;&gt; I'm a bit worried about your statement concerning the meta-meta-model </FONT>
<FONT COLOR="#000000">&gt;&gt; requirement (Ecore). Since we have no explicit models at all I'd like to </FONT>
<FONT COLOR="#000000">&gt;&gt; explain it in Java terms:</FONT>
<FONT COLOR="#000000">&gt;&gt; </FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt; Well, the OCL Abstract Syntax Model needs to be able to reference </FONT>
<FONT COLOR="#000000">&gt; model elements, and to persist those references via the usual EMF </FONT>
<FONT COLOR="#000000">&gt; mechanisms. That implied a requirement that the target metamodel be </FONT>
<FONT COLOR="#000000">&gt; EMF-based.</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; From an API perspective in a CDO client we have real EObjects in </FONT>
<FONT COLOR="#000000">&gt;&gt; memory. In fact they're typed CDOObject which extends EObject: </FONT>
<FONT COLOR="#000000">&gt;&gt; <A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=marku p"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&amp;view=markup</A> &lt;<A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=marku p"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&amp;view=markup</A>&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; From an implementation point of view the main difference between </FONT>
<FONT COLOR="#000000">&gt;&gt; EObjectImpl and CDOObjectImpl is that the latter does not store the </FONT>
<FONT COLOR="#000000">&gt;&gt; modeled state in Java instance fields but instead somewhere in the </FONT>
<FONT COLOR="#000000">&gt;&gt; associated CDORevision: </FONT>
<FONT COLOR="#000000">&gt;&gt; <A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&amp;view=markup</A> &lt;<A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&amp;view=markup</A>&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; Reflectively accessible via CDORevisionData: </FONT>
<FONT COLOR="#000000">&gt;&gt; <A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&amp;view=markup</A> &lt;<A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&amp;view=markup</A>&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; These CDORevisions are transferred over the network and stored somehow </FONT>
<FONT COLOR="#000000">&gt;&gt; in the CDO server. Notice that there is no dependenciy from CDORevision </FONT>
<FONT COLOR="#000000">&gt;&gt; on Ecore at all! A CDORevision is associated with a CDOClass which also </FONT>
<FONT COLOR="#000000">&gt;&gt; relates to an EClass but only in a sematical sense. There's no </FONT>
<FONT COLOR="#000000">&gt;&gt; dependency from CDOClass on Ecore. In general, everything in CDO that </FONT>
<FONT COLOR="#000000">&gt;&gt; passes the network is implemented in the cdo.protocol plugin which has, </FONT>
<FONT COLOR="#000000">&gt;&gt; again, no dependency on EMF/Ecore.</FONT>
<FONT COLOR="#000000">&gt;&gt; </FONT>
<FONT COLOR="#000000">&gt; If you have CDOClasses paired with EClasses, then perhaps for OCL </FONT>
<FONT COLOR="#000000">&gt; purposes you could implement this mapping on-the-fly? The Environment </FONT>
<FONT COLOR="#000000">&gt; and EvaluationEnvironment APIs should be sufficiently abstract to </FONT>
<FONT COLOR="#000000">&gt; allow you to delegate the EMF-based access to the CDOClasses and </FONT>
<FONT COLOR="#000000">&gt; CDORevisions ... at least, if you can't, then perhaps this API needs </FONT>
<FONT COLOR="#000000">&gt; enhancement.</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt; </FONT>
<FONT COLOR="#000000">&gt;&gt; This is the situation: At the CDO server side we have no EMF, thus no </FONT>
<FONT COLOR="#000000">&gt;&gt; Ecore. But we have instances that support reflective access via a </FONT>
<FONT COLOR="#000000">&gt;&gt; dynamic model that semantically relates to an Ecore model. Btw. a </FONT>
<FONT COLOR="#000000">&gt;&gt; CDOClass looks like: </FONT>
<FONT COLOR="#000000">&gt;&gt; <A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&amp;view=markup</A> &lt;<A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&amp;view=markup</A>&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; Sorry for the lengthy monologue ;-)</FONT>
<FONT COLOR="#000000">&gt;&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; What makes me a bit more hopeful is your statement about SQL below </FONT>
<FONT COLOR="#000000">&gt;&gt; which, in itself, is not Ecore derived. Or do you mean something like an </FONT>
<FONT COLOR="#000000">&gt;&gt; SQL.ecore?</FONT>
<FONT COLOR="#000000">&gt;&gt; </FONT>
<FONT COLOR="#000000">&gt; </FONT>
<FONT COLOR="#000000">&gt; That's what I meant. In fact, the SQL metamodel from DTP.</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; Anyway, I suspect that you get an impression of the situation in a CDO </FONT>
<FONT COLOR="#000000">&gt;&gt; server. Do you think it's worth discussing whether/how your OCL </FONT>
<FONT COLOR="#000000">&gt;&gt; interpreter is able to validate CDORevision instances?</FONT>
<FONT COLOR="#000000">&gt;&gt; </FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt; Yes, it would make a good case study for the generality of the </FONT>
<FONT COLOR="#000000">&gt; metamodel-binding mechanism.</FONT>
<FONT COLOR="#000000">&gt; </FONT>
<FONT COLOR="#000000">&gt;&gt; And yes, if it'd be possible somehow, your contribution would be </FONT>
<FONT COLOR="#000000">&gt;&gt; welcome! ;-)</FONT>
<FONT COLOR="#000000">&gt;&gt; </FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt; Heh heh ... that's the trick, isn't it? Finding the opportunity to do </FONT>
<FONT COLOR="#000000">&gt; yet more work! :-P</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; Cheers</FONT>
<FONT COLOR="#000000">&gt;&gt; /Eike</FONT>
<FONT COLOR="#000000">&gt;&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; p.s. Will you be coming to ESE? Ed mentioned a modeling symposium a day </FONT>
<FONT COLOR="#000000">&gt;&gt; in advance...</FONT>
<FONT COLOR="#000000">&gt;&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; Christian W. Damus schrieb:</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; Hi, Eike,</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; Yes. Since the 1.1 release, MDT OCL supports the implementation of </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; &quot;metamodel bindings.&quot; Out-of-the-box, the MDT OCL SDK provides </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; bindings for Ecore and UML.</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; You need to ensure that your metamodel implements the constructs </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; required by OCL in some fashion: these are the notions of Classifier, </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; Operation, Property, etc. Your metamodel must be Ecore-based (Ecore </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; is the meta-metamodel). If these requirements are satisfied, you </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; basically provide three things:</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; * an EnvironmentFactory implementation (with an Environment and</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; UMLReflection implementation) for your metamodel</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; * a specialization of the AST model (the Types and Expressions</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; packages) that supplies the generic type parameter substitutions</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; that map your metamodel's constructs to OCL's parameters and</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; mixes in the generalizations of your metamodel's Classifier and</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; TypedElement constructs</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; * an implementation of the OCL Standard Library as an instance of</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; your metamodel</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; The Ecore and UML bindings provided by the SDK serve as examples, and </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; the Advanced Topics in the developer guide has a word or two to say on </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; the subject. I have seen evidence at EclipseCon of additional </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; metamodel bindings, and I have prototyped the concept with SQL, myself.</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; Perhaps I can contribute in some way? One tool that is lacking from </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; the MDT OCL SDK is the metamodel-binding generator. It's a lot of </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; work to build one by hand, and it could benefit a lot from some </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; automation.</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; HTH,</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; Christian</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt; On Thu, 2008-05-22 at 09:52 +0200, Eike Stepper wrote:</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt; Hi Christian,</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt; Is it possible to use OCL with non-Ecore based models?</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt; I ask this because Simon and I plan to develop a remote query mechanism </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt; for CDO and a CDO repository usually doesn't know about Ecore. </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt; Internally (over the network and in the server) CDO uses a different </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt; concept of CDORevisions which capture a single state in the lifetime of </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt; a client side EObject (instance level). At the model level CDO uses the </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt; concept of a CDOClass which is contained in a CDOPackage and has </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt; CDOFeatures. All these concepts are more or less mappeable to/from their </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt; Ecore counter parts.</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt; In addition it would be interesting to use OCL as a server side </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt; validation facility. Incoming CommitTransactionRequests could be </FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt; validated remotely before being applied to a backend.</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt; Cheers</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt; /Eike</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt;</FONT>
<FONT COLOR="#000000">&gt;&gt; &gt;&gt; </FONT>
<FONT COLOR="#000000">&gt;&gt; </FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-S03OkZHhym7xySay1BH2--
Previous Topic:querying across multiple XMI resources
Next Topic:Can OCL be used standalone?
Goto Forum:
  


Current Time: Sat Sep 20 02:13:11 GMT 2014

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

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