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

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

Hi all,

Terminology discussions can happen later, once we have decided what we
will do. We are getting off subject.

I'd like to express an opinion. It's mine alone, not Dieter's, not
PTC's.

Lofton, you keep saying users, but I really see one user, Boeing.

Andy DeWild (from United, right?) wants SVG-like animation in CGM, which
will never happen. I think we agree on that.

It's my understanding that most users have understood that CGM will
never have SVG like or Flash like animation. If you want that kind of
animation, you have to convert your CGMs to another format. If I
understood right, even the S1000D specification says to use formats like
SVG, Flash, MPEG, Avi etc... to get animation into your publication.

In WebCGM 2.0, we added XCF and DOM styling functions. So far we have
been receiving very little customer feedback about the DOM. Is it that
it takes a long time for folks to get used to it? Is it that folks are
using other technologies instead? Hard to say.

So I understand the group's frustration and the intent of doing
'minimal' SVG-like animation features; but I don't think DOM APIs is the
way to go. This group wrote papers on the matter, CGM is interoperable
(more than SVG). If we add DOM animation, that interoperability will
take a big hit. There's no way an authoring tool can understand
another's script.

Yes, declarative animation is a lot of work. And yes it probably is
beyond the scope of 2.1 given the size of the group. So what does the
group do?
- Research what is feasible using a transform interface; maybe some of
the other vendors are willing to do an experimental implementation?
- Go ahead now with a transform interface without the research? I don't
think we can stop you.
- Wait at a later time?

Regards,
Benoit.

 

-----Original Message-----
From: Lofton Henderson [mailto:lofton@rockynet.com] 
Sent: Tuesday, September 04, 2007 6:54 PM
To: Weidenbrueck, Dieter; cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] RE: about transform [was RE: [cgmo-webcgm]
Groups - Proposed WebCGM 2.1 ...]

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=g
l
>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