MHonArc v2.5.2 -->
ubl-ndrsc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [ubl-ndrsc] RE: [ubl-cmsc] Specialization Architecture (was FW:Another item for issue track ing list.)
Bill,
Well,
I do take Mette's point, deconstructed or not. She is looking at this from the
perspective of mapping XML types into Java types, which makes the issue of
polymorphism of very practical importance. If I understand correctly, you are
pointing out that Paella permits polymorphism because in essence any type is
compatible with the abstract base type. This is true, but it doesn't
let a polymorphic processor (like a Java compiler) that knows about the
base type do anything useful with the derived types, since the base type has no
semantics.
What
Mette is saying, I think, is that this is "chickening out" because we can
claim to support polymorphism without doing any valuable analysis of
what the immutable semantics of a type are. Derived types should
share these semantics so that polymorphism becomes useful. Of course, all your
examples are valid issues that we need to address (e.g. adding a new element in
the middle of content model, removing a required element, etc.). They are solved
by Paella but at the expense of sacrificing any real value provided by
inheritance relationships.
This
might turn out to be the best we can do. Nevertheless, we should be aware
that there is a big cost to giving up useful polymorphism, and
consider the possible alternatives seriously:
1) Give up on inheritance relationships
altogether and go the TAAT route. At least we're calling it what it is (i.e. not
derivation but a transformation).
2)
Model base types carefully to enable the most possible flexibility. Force people
to conform to these base types. Have the courage of our convictions! (I assume
this is what Mette is getting at.) This is probably going to end up looking like
xCBL (i.e. gobs of optional stuff) and has its own issues.
3)
Think about what is wrong with XSD derivation and come up with a mechanism that
better fits our requirements. Somehow get it blessed and integrated into
tools.
I
confess that I prefer route 3) despite the fact that it seems very
idealistic. I would be for completely forgoing XSD derivation, designing our own
UBL derivation mechanism linked to the CM and publishing it so that tool vendors
can support it, if they wish. No one really supports XSD derivation properly
anyway, so we're not giving up that much.
Matt