RE: [cgmo-webcgm] Straw horse application structures

["Bezaire, Benoit" <bbezaire@ptc.com>]

Hi Stuart,

I'm not sure what to say about your email. It is closer to what we have
implemented than anything suggested so far, which makes me happy.

A couple of comments:
- I still think we don't have clear enough requirements. We've made
progress on the 'flow' requirements with the line style and start
offset, which is good. But we haven't gone into the specifics of the
'transforms' requirement. I think we should focus on that.

- I'm not sure I like the idea of animation in the XCF. Yes, we do it
ourselves, but it was the only way we could remain compliant with the
specification. Having the animation in the XCF has advantages (ex: CGM
remains 'static' graphics only), but there are also disadvantages (ex:
users can mess up the animation with a text/xml editor). We should be
careful here.

- Would transforms be additive or not?; assuming we come up with
requirements for this. See problem below:

(simplified markup)
APS 'myAps'
  // geometry is here
  APS 'aSequence'
    APS 'aStep'
      APS translate 50, 100
	EndAPS
    EndAPS
    APS 'aSecondStep'
      APS rotate 50, 100, 45
	EndAPS
    EndAPS  EndAPS
EndAPS

// in js script (approx code)
var aps = picture.getAppStructureById("myAps");
aps.firstStep(); // this should apply the translate the first translate
aps.nextStep(); // this should apply the second step (the rotation)

Where does the rotation take place? at the new position after the
translate or at the old position before the translate? It would be
important to know because the rotation center point needs to be exact!

For the DOM interface, I would build on what you suggested and re-word
it as follows:
option 1: use list concept
APS.GetSequences... returns a list of Sequences
Sequences.GetSteps... returns a list of Steps
Step.apply()... applies the current Step

option 2: use first/next concept
APS.GetFirstSequence... returns a Sequence
Sequence.GetNext()... return the next Sequence
Sequence.GetFirstStep... return the first Step in the current Sequence
Step.GetNext... return the next Step
Step.apply()... applies the current Step

Regards,
Benoit.

-----Original Message-----
From: Galt, Stuart A [mailto:stuart.a.galt@boeing.com] 
Sent: Wednesday, October 10, 2007 6:38 PM
To: cgmo-webcgm@lists.oasis-open.org
Subject: [cgmo-webcgm] Straw horse application structures

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