Re: [m2m-atl-dev] XSD->ECORE->ATL - type conversion failures

["Frédéric Jouault" <frederic.jouault@xxxxxxxxxxxxxx>]

Hi Martin and Dennis,

> A similar issue has come up before, regarding mixed content in XSD-based
> meta-models. It is documented in Bug # 156094:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=156094
>
> The asm2EMF() and emf2ASM() methods have been modified to support the
> EMF FeatureMap.Entry objects. The ASMTuple type has been used to
> represent this EMF object in "ASM-land".

Dennis is right: model handler specific type conversion should be
performed in the corresponding driver (i.e., class ASMEMFModelElement
of emf4atl for EMF).

Note that it is always possible to define a new driver for specific
cases that do not fit the general case, as we did for UML2. However,
this is probably not be necessary to handle XSD types.


> As for extensibility: I was under the impression that Ecore supports a
> fixed set of primitive types as does ATL's ASM format. The problem is
> that the mapping between both is apparently not complete.
>
> While you could probably do some conversion hacks for BigInteger and
> BigDecimal, you'll likely run into problems later. I think the native
> ASM library needs two extra ASMNumber subclasses to properly represent
> these types. The fact the Ecore does not have an infinite amount of
> primitive types makes this exercise worthwhile. What do you guys think?

ATL types are based on OCL types, not EMF types. However, this should
not be that big an issue, unless arbitrary Java types are used (i.e.,
by playing with instanceClassName, as I have seen it done a couple of
times)..


Currently, it is possible to add and/or replace operations. It would
be nice to be able to add and/or replace types.

Obviously, adding types should be reserved for specific purposes
(e.g., using the ATL VM for other languages), because it generally
requires language-level support as well.

However, replacing types may have some interesting uses. For instance,
although int should probably remain the default Java type mapping for
OCL Integer, it might be useful to have a BigInteger alternative.


Regards,

Frédéric