Straw horse application structures

["Galt, Stuart A" <stuart.a.galt@boeing.com>]

Hello all,

Okay, I have spent some time reading SVG animation [1] and SMIL [2].  I
guess that implementing full blown animation as part of webCGM 2.1 would
be too much work.  However, I think that we can lay the groundwork by
defining the supporting infrastructure to handle some of the easy stuff.
The film-strip or "budget" animation (yes I know that might be the wrong
word) is described in SMIL as the calctype="discrete" mode.

I no longer want animation, I want sequential discrete transformations
:) 

My proposal would be to introduce some new application structures that
can be either embedded within the CGM image or expressed in an XCF file.
All that is needed is that the application structures exist in the DOM
tree after the image is loaded.

An important design decision to make early on is do the sequence and
steps have to be a child of the grobject that is being transformed?  I
would prefer the answer to be no but then you need to have an ability to
call out the apsId .

Here are the application structures that I have come up with:

APS sequence:
An apsId is required.  A targetId would be optional but if it is not
specified the targetId would need to be defined for all of the
individual steps.  I think this is similar to the structure that Benoit
talked about minus any attributes that have to do with timing.

APS step:
A targetId would optional, but if it is not specified it would need to
be specified in the parent APS or all of the atoms would need to be
specified.  Once again it is similar to the structure that Benoit talked
about minus any attributes that have to do with timing.

I would also define the following "atom" application structures:  (note
that apsId is optional)

Style ( apsId?, styleName, styleValue ) - this would the names and
values that can be set via the DOM

Translate(apsId?, dx, dy) - this just takes all of the x and y
coordinates within the APS and translates them by dx,dy

Scale(apsId?, orgin, sx, sy) - this just scales about the specified
orgin. 
X(new) = (X(old) - x(origin)) * sx + X(origin)

Rotate(apsId, origin, angle) - this rotates the apes angle degrees
around the origin.

By restricting ourselves to calctype="discrete" type of animations I
would expect all of the atoms of a step to be implemented at once.

To be able to make something happen the sequence APES structure needs to
be visible in the DOM so I can get to it.  I would then propose the
following methods:

firstStep() - This applies the atoms contained in the first step.
lastStep() - This applies the atoms contained in the last step
applyStep(n) - This applies the atoms contained in the nth step.  If n
is <0 or > number of steps and exception should be thrown?
nextStep() - This applies the atoms contained in the next step.  Not
sure how to handle the case when we apply the last step and ask for one
more... does this return a value or should an exception be tossed?

If this gets delayed and becomes part of a longer term project timing at
the sequence and step level could be added.  Adding a path atom might
also prove useful.

[1] http://www.w3.org/TR/SVG11/animate.html 
[2] http://www.w3.org/TR/smil-animation/




--
Stuart Galt
SGML Resource Group
stuart.a.galt@boeing.com
(206) 544-3656