Re: [mdt-ocl.dev] OCL delegate namespaces

["Willink, Ed" <Ed.Willink@xxxxxxxxxxxxxxx>]

Yes. Sorry. 

> -----Original Message-----
> From: mdt-ocl.dev-bounces@xxxxxxxxxxx 
> [mailto:mdt-ocl.dev-bounces@xxxxxxxxxxx] On Behalf Of Axel Uhl
> Sent: 03 February 2011 15:43
> To: MDT OCL mailing list
> Subject: Re: [mdt-ocl.dev] OCL delegate namespaces
> 
> Do you mean o.e.o.examples.xtext.tests?
> 
> On 2/3/2011 4:34 PM, Willink, Ed wrote:
> > Hi Axel
> >
> > All the tests are in:
> >
> > o.e.o.examples.xtests
> >
> > The ...BooleanTests etc demonstrate query evaluation
> >
> > The SerializeTests (4 failures) demonstrate Ecore loading 
> saving etc.
> >
> > Documentation happens after M7 ...
> >
> > 	Regards
> >
> > 		Ed
> >
> >> -----Original Message-----
> >> From: mdt-ocl.dev-bounces@xxxxxxxxxxx
> >> [mailto:mdt-ocl.dev-bounces@xxxxxxxxxxx] On Behalf Of Axel Uhl
> >> Sent: 03 February 2011 15:31
> >> To: MDT OCL mailing list
> >> Subject: Re: [mdt-ocl.dev] OCL delegate namespaces
> >>
> >> Ok, well, let's just see how it turns out. I've been 
> checking out the
> >> examples.pivot bundle today and took a quick look. I can't
> >> seem to find
> >> any test cases, doc or other material explaining how to use it in
> >> conjunction with an Ecore model. Any pointers you can provide?
> >>
> >> Best,
> >> -- Axel
> >>
> >> On 2/3/2011 1:56 PM, Willink, Ed wrote:
> >>> Hi Axel
> >>>
> >>> Just found thios on my work email; did'nt arrive at 
> home.. strange.
> >>>
> >>>> we should check what else may depend on o.e.o.ecore. 
> Obviously, the
> >>>> Impact Analyzer in its current implementation is 
> specific to it and
> >>>> would need adjustments to work with o.e.o.pivot. It may also
> >>>> be useful
> >>>> to ensure that there are no major performance hits. In
> >> particular, I
> >>>> hope we can make the latest changes we applied to the o.e.o.ecore
> >>>> evaluator regarding the "inlined" use of the cached
> >> compiled delegate
> >>>> expressions also available for the o.e.o.pivot implementation
> >>>> (if that
> >>>> isn't already the case).
> >>>
> >>> I'm not pushing for total migration until I have used it a
> >> bit more and
> >>> the notional UML-alignment becomes more pedantic.
> >>>
> >>>> It may also be worthwhile understanding ramifications
> >> external to the
> >>>> project's codebase. How much do we know about the use of
> >>>> delegates with
> >>>> their specific URI and any dependencies of such clients on the
> >>>> particular metamodel being used (Ecore, UML, Pivot)?
> >>>
> >>> Nobody is yet using Pivot. UML is distinctly limited,
> >> although in migrating
> >>> the OCL Console, it appears to have full control for UML;
> >> I've just never
> >>> seen it
> >>> work.
> >>>
> >>>> Has concrete syntax compatibility across Ecore and Pivot
> >> already been
> >>>> analyzed? Can users assume that their expressions will flawlessly
> >>>> compile when we redirect to Pivot, or how much adjustment
> >>>> will be required?
> >>>
> >>> Both old and new parsers aspire to 100% grammar compliance
> >> although the OMG
> >>> specification has made greater than 99% unachieveable
> >> objectively. The old
> >>> parser had a lax-null option to deviate from the letter of the 2.0
> >>> specification.
> >>> It turns out that lax-null is much closer to the OCL 2.3
> >> clarification of
> >>> null
> >>> and invalid.
> >>>
> >>> The old parser is unlikely to change very much. The new
> >> parser will converge
> >>> on OMG as OMG gets clearer.
> >>>
> >>> In principle, most things will just work. Of course
> >> anything involving eXXX
> >>> was broken in Helios M4. The Pivot Model should support
> >> container(), which I
> >>> really must implement.
> >>>
> >>> It should be possible to retrofit the old parser semantics
> >> onto the Pivot
> >>> model
> >>> by defining an MDT-OCL-1.3.0.oclstdlib. Not high up my 
> priorities at
> >>> present.
> >>>
> >>> 	Regards
> >>>
> >>> 		Ed Willink
> >>>
> >>> Please consider the environment before printing a hard 
> copy of this
> >>> e-mail.
> >>>
> >>> The information contained in this e-mail is confidential.
> >> It is intended
> >>> only for the stated addressee(s) and access to it by any
> >> other person is
> >>> unauthorised. If you are not an addressee, you must not
> >> disclose, copy,
> >>> circulate or in any other way use or rely on the
> >> information contained in
> >>> this e-mail. Such unauthorised use may be unlawful. If you
> >> have received
> >>> this e-mail in error, please inform us immediately on +44
> >> (0)118 986 8601
> >>> and delete it and all copies from your system.
> >>>
> >>> Thales Research and Technology (UK) Limited. A company 
> registered in
> >>> England and Wales. Registered Office: 2 Dashwood Lang Road,
> >> The Bourne
> >>> Business Park, Addlestone, Weybridge, Surrey KT15 2NX.
> >> Registered Number:
> >>> 774298
> >>>
> >>> Thales UK Limited. A company registered in England and
> >> Wales. Registered
> >>> Office: 2 Dashwood Lang Road, The Bourne Business Park, 
> Addlestone,
> >>> Weybridge, Surrey KT15 2NX. Registered Number: 868273
> >>> _______________________________________________
> >>> mdt-ocl.dev mailing list
> >>> mdt-ocl.dev@xxxxxxxxxxx
> >>> https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
> >>>
> >>>
> >> _______________________________________________
> >> mdt-ocl.dev mailing list
> >> mdt-ocl.dev@xxxxxxxxxxx
> >> https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
> >>
> > _______________________________________________
> > mdt-ocl.dev mailing list
> > mdt-ocl.dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
> >
> >
> _______________________________________________
> mdt-ocl.dev mailing list
> mdt-ocl.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
>