Ideas about a Transform Interface

["Ulrich Laesche" <ulrich@ematek.de>]

Hi All,

Attached you will find a statement from our dev team, summarizing their
opinion about what could be done regarding a transform interface. It is
not a concrete spec but provides ideas for discussion based on the last
phone conference. There is also a second statement by myself, trashing
all of this and suggesting a much simpler approach. First comes the
team's statement:

"We have read the according chapter from SVG, and it seems that it's
exactly what needs to be done for CGM regarding animation, probably in
some simplified version. SVG has all these transformations, moving,
rotation, scaling, also timing, and it works there already.

From our point of view, if we don't want to reinvent the wheel,
animation needs to be done using the existing SVG transform approach
with some adaptions. For example, in WebCGM, the objects (e.g., the APS
types 'para', 'subpara', 'groject') are used for navigation and picking
operations. We think the simplest is to add here more (transformation)
operations, like movement, rotation, scaling and so on. Viewers already
are supposed to do something with the APS (scale them to fit, or
highlight), so they would just need to implement more operations.
Currently, the exact viewer behavior is controlled be a set of "object
behavior keywords", associated with the link, and the presence or
absence of certain "APS attributes" on the object ('viewcontext',
'region', etc). (This is a phrase from the WebCGM documentation).

Looking at the table enumerating the object behaviors available in
WebCGM 2.0 (containing "full", "zoom", "move", "newHighlight",
"addHighlight", etc) we could add more keys here, such as "moveAPS",
"rotateAPS", "scaleAPS"...  Furthermore, we could extend the APS
attributes. There are already attributes with similar meanings, such as,
'visibility', 'interactivity', 'linkuri'...  So, we could add the
keyword 'animation', which means, that when its value is 'on', a viewer
has to apply the 'object behavior' keys to this APS (moveAPS,
rotateAPS...). Whether or not the animation actually occurs needs to be
defined via the WebCGM event model, which is triggered via API call or
some other actions (mouse movement, mouse click, initial loading...).

SVG uses a lot of different "transform" animations, we can just take
some of them:

transform(a,b,c,d,e,f) - which means mathematical transfromation with
matrix [a,b,c,d,e,f]
translate(x,y) - which means just move with offsets x,y
scale(x,y) - scale along the x,y
rotate(angle) - rotate
motion(path) - move the APS along the motion path, where path will have
several parameters, like "from" (initial position), "to" (end position),
"duration" (how quick), "counts" (number of intermediate positions), and
so on...

The described approach deals with WebCGM on an element level, i.e.
requires changes to the WebCGM document itself. Another approach would
be to just add some DOM API commands for animation, but from our point
of view, if the movement is not defined in the document itself, then the
externally triggered actions will not result in anything good. For
example, you have two rectangles one by another. Then you move one and
it will appear on top of another. Thus, the possibility of movement of
the rectangle, and the limits of such a movement, should be defined
inside the document. The API should just trigger this movement."

So far the team's statement, which leans to Benoit's preference of
keeping animation in the file. In the opposite, I would say that
completely relying on 4-5 external DOM API calls for transforms is OK.
There are two reasons. As a reply to the problem of overlapping
rectangles (see above), or of user defined change of the coordinate
system, I would say we are talking about budget animation. If somebody
wants to go this route it would only be fair to offload responsibility
regarding the results of budget animation to the script writer without
having to offer too much of protection. Secondly, we may very quickly
agree on the exact syntax of 4 or 5 additional DOM calls, such as
"Rotate(APSid, rotation angle)" or "Move(APSid, newx, newy)" (point of
reference could be center of APS etc), but it can be foreseen that
adding CGM transform elements will take some time for specification.

The negative impact of the pure DOM API based approach is that we won't
lay any foundation for future animation related work, but I am still in
favour of it in the scope of the 2.1 standard.

Looking forward to your replies
Ulrich