RE: [cgmo-webcgm] RE: about transform [was RE: [cgmo-webcgm] Groups - Proposed WebCGM 2.1 ...]

[Lofton Henderson <lofton@rockynet.com>]

At 05:59 PM 9/4/2007 -0400, Weidenbrueck, Dieter wrote:
>[...]
>SVG defines animation as the ability to change vector graphics over time
>[1], and it is based on SMIL, another standard. We should not introduce
>a new definition of animation.

Without getting hung up on terminology, we are talking about something 
animation-like that users are currently doing, and showed to us, and would 
like better, more efficient support for.

If someone can think of a different term for it (other than "marquee 
animation" or "discount animation" or "discrete animation"), feel free to 
offer it -- I'm fully sympathetic.  But that's what the users were calling 
it -- animation of some ilk or another.

I would sympathize with some terminology that distinguishes it from full, 
smooth-time SMIL/SVG animation.


>At the same time, applying a transform (move, rotate, scale), is clearly
>a DOM method [2]. Again, why should we choose a different way for CGM?

I'm not understanding the point here.  Explain?  Yes, transform is a DOM 
method.  It is also defined in SVG content instances, right?  In other 
graphics standards (such as CGM, but not allowed in WebCGM), it is part of 
the content of instances of the standard.

If I recall, the prevailing thinking at Seattle is that it should be a 
Style Property.  Hence it is available though the DOM, and available 
through XCF, like all Style Properties.

Finally, I want to remind that the proposed Style Property is not 
equivalent to changing geometry of primitives (as you mentioned once 
earlier). We are not going down to leaf nodes (within objects), and we are 
not editing the graphic.

It is a transient visual effect, like all Style Properties.  We are 
proposing it for specific reasons such as this...  Right now, CGM users are 
doing and have shown us this:  save two pictures of the console dial as 
objects or layers, one rotated 45 degrees from the other, and then use 
'visibility' through the DOM to alternate between them.  They could instead 
do this:  alternate a Style Property through the DOM between 
rotate(myDial,45) and rotate(myDial,-45), with only one copy of the object 
myDial needing to be in the picture.


>I have no objections to start a discussion about expanding the WebCGM
>DOM, however,
>- this is not animation

I agree that what we are talking about actually adding to the WebCGM spec 
is not animation per se.  It is what I would call (in a tutorial, if not in 
the standard itself) "animator hooks" or "animation enablers" -- it 
facilitates users to create script-based discrete "animations", as they are 
already doing with other style properties and visibility attributes to 
create their so-called "marquee animation".

>- there are better ways to accomplish these kind of things than trying
>to   script transforms from the outside.

Andy DeWild wanted, effectively, the functionality that could only 
reasonably be provided with embedded, full declarative animation.  We told 
him that we thought it was beyond the scope of what we could offer short 
term and get implementation commitment for.

I don't think anyone will argue with your statement for that level of 
"animation".  On the other hand, would you argue that scripting every 
possibly object or layer position/orientation with visibility toggling (as 
M&L now do) offers a better user experience than scripting an alternating 
transformation property on one copy of the object?

Cheers,
-Lofton.


>I remind everybody of the hotspot overlays in SGML, and the nightmares
>they caused. There is absolutely no reason why we should make the same
>mistake again.
>
>Regards,
>Dieter
>
>
>[1] http://www.w3.org/TR/SVG11/animate.html#Introduction
>[2] http://www.w3.org/TR/SVG11/coords.html#InterfaceSVGTransform
>
>
>-----Original Message-----
>From: Cruikshank, David W [mailto:david.w.cruikshank@boeing.com]
>Sent: Dienstag, 4. September 2007 23:49
>To: Weidenbrueck, Dieter; Lofton Henderson; Bezaire, Benoit;
>cgmo-webcgm@lists.oasis-open.org
>Subject: RE: [cgmo-webcgm] RE: about transform [was RE: [cgmo-webcgm]
>Groups - Proposed WebCGM 2.1 ...]
>
>Dieter,
>
>While animation is the movement of something through time, I don't think
>our requirements view "time" as an absolute.  There are lots of
>defintions of animation on the web (see:
>http://www.google.com/search?hl=en&defl=en&q=define:animation&sa=X&oi=gl
>ossary_definition&ct=title). My favorite is "The way objects enter
>and/or exit a PowerPoint slide."  Some of the animation that Molly
>described was exactly that.  Movement of an object from point A to point
>B.  Molly would look at it and say I'll probably generate 29 copies of
>that object along the path from A to B and turn the visibility off and
>on to create a "pleasing" movement.  She didn't say "I have to move this
>object from point A to point B in 3.48 seconds".
>
>So in my opinion, transforming an object to move it or rotate it is
>animation even if it's not tied to a specific time line.
>
>Thx...Dave
>
>
>Technical Fellow - Graphics/Digital Data Interchange Boeing Commercial
>Airplane 206.544.3560, fax 206.662.3734 david.w.cruikshank@boeing.com
>
>-----Original Message-----
>From: Weidenbrueck, Dieter [mailto:dweidenbrueck@ptc.com]
>Sent: Tuesday, September 04, 2007 2:11 PM
>To: Lofton Henderson; Bezaire, Benoit; cgmo-webcgm@lists.oasis-open.org
>Subject: RE: [cgmo-webcgm] RE: about transform [was RE: [cgmo-webcgm]
>Groups - Proposed WebCGM 2.1 ...]
>
>Lofton,
>
> >I think there was general agreement (heeding the experienced advice of
> >Itedo!) that declarative animation is beyond the scope of a "quick
>2.1".
>
>Our point was that it doesn't make sense to start to work on something
>big like declarative animation given the small list of people who may
>contribute to this kind of work. Very quickly the discussions would
>become lengthy, just look at the SVG story.
>Also, there should be early discussions with W3C about their opinion
>regarding animation in CGM, given the fact that SVG already supports
>animation.
>So I think animation is not only beyond the scope of 2.1, we shouldn't
>start it unless we have resources and timely implementations.
>
>
>What we are discussing now has nothing to do with animation at all, and
>it shouldn't be called this way. We are simply applying geometrical
>transforms to static objects, happening immediately. There is no
>timeline or similar involved.
>You could also say that we are switching modes, e.g. switch open or
>closed.
>
>So if we expand the DOM to support changing geometry, we open a box that
>we had kept closed so far, which is access and manipulation of
>primitives and coordinates.
>
>I completely understand that users try everything to accomplish their
>goal, however, I am not inclined to introduce something that already
>failed inside SVG here.
>
>I will try to be on the call tomorrow, we can discuss then.
>
>Regards,
>Dieter