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

[Martin J Bartlett <jbartle9@xxxxxxx>]

More food for thought (I always seem to be complaining - let me say that
the use of ATL in our current project has really impressed mnagement with
the amazing time savings it has given us, and the flexibility it has
allowed us, in what we are doiung :-)).

Ecore has a well documented xsd-type->java-type mapping, which it uses when
building an ecore from an xsd.

For the most part ATL can cope with the mapped types - except for anything
that maps to java.math classes (there are quite a few xsd types that do!).

In investigating why we couldn't get the value out of our
"xsd:integer"-based feature, I also discovered that the type system is not
extensible - checks exist in various places embedded in the ATL code
without the possibility of extending through subclasses or providing plugin
additions to type.

The first of these problems absolutely needs addressing - for now we can
try and force the ecore to use java.lang.Long but we run the normal risks
of this kind of "cast" activity. The mapping of xsd->ecore is well
documented and has been in place for a number of years. XSD-based ecores
are ubiquitous. It's certainly causing us a fundamental problem at the
moment (modelling a schema, the content of which we have no control over).

The second of these issues should really be addressed too because people
CAN change the mapping in an ecore to anything they want - and in so doing
break an otherwise straightforward transformation subject.

Martin Bartlett


CSC Financial Services SAS
Registered Office: 14 Place de la Coupole, Axe Liberté, 94220 Charenton Le
Pont, France
Registered in France: RCS Créteil B 323 127 332

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------