[trans] - Model comments

[David Berry]

On Wed, 11 Mar 2020 at 14:21, CresitelloDittmar, Mark
<mdittmar at cfa.harvard.edu> wrote:
>
> David,
>
> I'll just put in my $0.02 on this since it can be hard for others to consider the details.
>
> 1) As shown, this would pass vo-dml validation, though Gerard points out that it should not due to the child->parent composition.
>     o the * multiplicity on Mapping would not be a problem since Mapping is an ObjectType.

Hopefully the second version I sent out solves that by using the
MapRef class that reflects the suggestions that both you and Gerard
have made.

> 2) As shown, the definition of Mapping becomes somewhat muddled.
>     I've tried to keep with the definition that
>       Mapping == the bi-directional relation (between 2 frames), has 'forward' and 'inverse' concepts
>       Transform (TOperation) == unit-directional mathematical operation
>
>    With this model, the Operation gets denormalized with the Mapping, so
>      o some are bi-directional (Unit, Scale), some uni-directional (Permute, Poly2D), and Matrix may be either.
>      o the profile for each Mapping is different (has the parameters of the operation)

For me the distinction between an Operation and a Mapping is a bit
muddled as many operations are in fact bidirectional. I'm just not
sure that the extra complexity involved in distinguishing between
uni-directional operations and bi-directional mappings at the root of
the model buys us anything extra that is not also provided by the
simpler idea of a providing a single subclass of CompoundMap that
defines inverse and forward transformations using two Mappings. If you
consider the two equations "Y=X+1" and "Z=X+Y" are they fundamentally
different just because one can be inverted and the other can't? I'd
say not.


> 3) The current model is factoring in a requirement that a Mapping must be able to explicitly define the forward and inverse operation.
>     This model reverts to the original assertion that forward and inverse are methods on Mapping (formerly Transform), which may or may not produce results. The only type guaranteed to have both is BiDirectional, where the 2 component Mappings are for forward and inverse specifically.

If I'm understanding things correctly, both schemes meet that
requirement. My proposal meets it via the BiDirection class and yours
via the distinction between operations and Mappings.  From experience
with AST I'd say that it should be legal to have a Transform that is
defined in only one direction. AST provides for this via the
TranForward and TranInverse attributes (e.g. see
http://www.starlink.ac.uk/docs/sun211.htx/sun211ss436.html).


> In short..
>   + I definitely prefer separating Operation from Mapping.. and I think, is needed to support #3 above.
>   + but if we remove the requirement in #3, a variation of what you show is workable.

I think we should allow for Mappings that can transform only in one
direction. I've come across the need for such Mappings in several
different contexts.

David