[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[omelet-dev] UML to XSD bidirectional transformations

Hi Dave

You wrote on the newsgroup:
>I am very interested in collaboration related to bi-directional
>transformation between UML2 and XSD. I started work on an XSD profile
for
>UML2 and converting my earlier work on this topic (see my web site at
>www.xmlmodeling.com).  I created an Eclipse plugin called hyperModel
that I
>have not yet updated to Eclipse 3.0.

I've looked at hyperModel and it seems quite interesting in so far as it
goes, but of course you suffer like so many other projects from no
decent
extensible UML editing plug-in for Eclipse. I refuse to use Rose for
Open Source activity, though it must be supported for those who do,
and I don't like ArgoUML very much so it's always a problem. Another
project ...

[Minor critique: I could New an Association but not a Generalisation.]

I'm not quite sure where you're trying to get to. You say bidirectional
UML
to XSD transformation, but UML use cases/state machines do not make
sense in XSD and some XSD constructs are too perverse for UML.

I presume you mean MOF, which is what I want too, except I would broaden
to arbitrary inter-transformation between as large as possible sub-sets
of
each of MOF, XSD, EMF, DTD, ... in as many different dialects of XML etc
as possible.

I see two different perpectives on schemas/meta-models. The
user-friendly
perspective allows a user to use a (possibly graphical) notation that
they
find easy to understand and manipulate. The checker-friendly perspective
supports a precise distinction between valid and invalid meta-model
instances.

The user-friendly perspective is highly subjective so we should support
whatever
users want.

Considering the checker-friendly perspective, we have the obvious
property that all equivalent schemas should make exactly the same
discrimination between valid/invalid otherwise we have semantic
ambiguities. 

I find it helpful to think of the checking process in a potentially
brute
force normalised form, with a lists of constraints for each state of a
checking automaton and rules for progressing between states. All schemas
can be converted to a normalised form with very few concepts - my
FlatSchema
model in the omelet.schema plug-in is like this. Practical schema
languages
have elaborate constructs, such as inheritance, that allow constraints
to
be shared between related states, and this is very convenient for the
user
but unnecessary for a simple normalised checking automaton.

We may therefore convert any schema language into normalised form, and
in doing so we can concentrate on accurate realisation of the subtle
semantics of a particular language.

We can naively translate normalised form into any schema language by
direct mapping of the simple concepts. This will often result in a very
large schema - accurate but not human-friendly.

We can translate the normalised form intelligently by re-using the
forward
translation, if we have expressed it as a mapping from source construct
to
consequent patterns. Recognising these patterns in the normalised form,
may give more respectable schema. (e.g. Any type whose definition
incorporates
all the elements and attributes of another with identical constraints,
and 
whose references are substitutable for that type can be made a subtype).

The above summary is the result of the last few months of intermittent
ponderings. I was originally concerned that my intermediate schema was
just yet another schema language, that I would like better because it
was
mine. I now see that because it is a normalised form with very few and
hopefully very obvious semantics, it enables the major difficulties of
translation to be resolved. MOF classes are not the same as XSD types,
and so MOF to XSD and vice-versa is difficult because of the need to
adjust concepts.

Implementing MOF->normalised or normalised->MOF requires only a
disciplined reading of one specification at a time, so just may be
it can be done accurately. Similarly XSD->normalised or normalised->XSD
or whatever.

If meta-modelling is to take off as the foundation for disciplined
models and model translations, it is essential that meta-model semantics
are very accurate, otherwise the difficulties of interpretation found
in XMI with today's tools will seem like child's play in comparison.

I hope this makes sense, and we can put it all in place. For OMELET,
we require accurate transformations between all the different
meta-modelling
formats. I don't care what language they're written in, just so long as
they can use only Open Source compilers and can be invoked from Java. My
current preference is XSLT (or rather my NiceXSL front-end), but that's
only until QVT takes off. With the relevant meta-models and
transformations
registered with OMELET, the framework should enable higher level tools
such as hyperModel or its successor to present the facilities in a user
friendly fashion.

[I'm getting married in just over a week so I won't have too much
time for correspondence for a while.]

	Regards

		Ed Willink