RE: [cgmo-webcgm] Flow of electricity

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

No it wasn't a proposal, but yet, there was very little feedback on the
matter.

Dieter's action item is complete. The email that I sent the group is the
subset of declarative animation. If you disagree that it was completed;
I would like to know why. 

Benoit.

-----Original Message-----
From: Lofton Henderson [mailto:lofton@rockynet.com] 
Sent: Wednesday, October 03, 2007 9:55 AM
To: Bezaire, Benoit; cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] Flow of electricity

At 08:59 AM 10/3/2007 -0400, Bezaire, Benoit wrote:
>I'm getting tired of these threads.
>
>I was disappointed with the progress made in Seattle. I was 
>disappointed by the minutes upon my return from vacation. Before I 
>left, PTC sent a detailed message about it's declarative animation 
>support. We got no feedback (again).

Was that a proposal?  I thought it was just an explanation.  I did ask
clarification on several points, got answers on a couple, and am
satisfied that I understand it.  I have been awaiting a proposal, as
in...

>I was expecting a Transform proposal, but it seems like there was a 
>misunderstanding.

In general, the TC's performance on AI completion is poor, and needs
improvement, and this includes PTC:  "Dieter volunteered to present a
subset of declarative animation, but will not be able to do it until the

telecon of 26 Sep."   (I understand that everyone is busy, but ... it is

hard to discuss something complex like a declarative animation subset
proposal in telecon without having been able to see and read it.)

-Lofton.

>Where does that leave us? I think it
>leaves us with Forrest email (Sept 11):
>
>Move, rotate or scale an object.
>Show progressive movement of liquid, gas or current through a wire or 
>pipe Show directional flow of liquid, gas or current in a wire or pipe 
>Show changes in levels of liquid in a container A method that would 
>switch between two styles of an object periodically.
>(flash or blink)
>Pan or zoom to a section of the drawing.
>
>I don't have any other requirements to forward the group. I guess I'll 
>wait.
>
>Benoit.
>
>-----Original Message-----
>From: Lofton Henderson [mailto:lofton@rockynet.com]
>Sent: Tuesday, October 02, 2007 6:36 PM
>To: Bezaire, Benoit; cgmo-webcgm@lists.oasis-open.org
>Subject: RE: [cgmo-webcgm] Flow of electricity
>
>Benoit et al --
>
>I have been reading and pondering all of this thread.  I'll dump some 
>cumulative thoughts in reply to Benoit's opinion piece...
>
>At 10:50 AM 10/2/2007 -0400, Bezaire, Benoit wrote:
> >Hi Stuart,
> >
> >That's a nice little animation. Clever!
> >
> >If I remember correctly, we do have a remove style... you have to do:
> >setStyleProperty( prop, "inherit" );
> >
> >I have a felling I'm not about to make any friends with what I'm 
> >about to say; but I have to say it since I think it matters.
> >
> >Although the result Stuart generated is good looking (which is a 
> >great positive), I would not encourage users to do this. I would 
> >argue that it takes too long to author such an animation. Equivalent 
> >results can be achieve faster in other file formats.
>
>Hmmm, that sounds to me like, "...instead producing some JavaScript, 
>you should convert your graphics to another format and don't use
WebCGM".
>Some people (Molly/Larry at least, and maybe only them) seem to buck 
>this advice.
>
>Stuart's code is similar in effect to one of the Boeing examples 
>(demo'd by M&L at Seattle F2F).  But its implementation is *much* 
>simpler than how they are now achieving the same effect with CGM.  M&L 
>have apparently rejected other formats like Flash.
>
>I agree with what several people have said in this thread -- whatever 
>the nature of any further potential animation support in WebCGM, we do 
>not imagine many people hand-coding these things.  (What do you think 
>this is, SVG?  ;-)  )
>
>Even the current (CGM) Boeing animations, which are much more complex 
>structurally, are produced by tools and experts, not by end users.
>
>
> >If we want animations to be frequently used in CGM we need easier 
> >methods than what is shown in this example (I'm mostly referring to 
> >the flow aspect). The electrical path was broken down into multiple 
> >fragments, then each were assigned a specific name/id. I would argue 
> >that most revisions of this illustration breaks the animation.
>
>Well, Stuart's animation is manipulating the visible styles and 
>attributes of named objects.  Therefore, would it be any worse than 
>XCF-based declarative animation (an external file that attaches 
>animation declarations to named objects)?
>
> >Additionally, I suspect that customers wiring diagrams are 20x more 
> >complex; thus, authoring animation must be much easier.
>
>Point of information... The real M&L sample was indeed based on a much 
>more complex diagram.  But they were still step-animating just a 
>handful of circuit pieces (line segments) in any one animation 
>sequence.
>
>
> >Attached is an example of what I mean (in SVG). Displayed are two 
> >(out of many) ways of showing flow, both used at the same time. In 
> >this example, if the wire (say during a revision) goes from a 
> >rectangle to a some sort of polygon, or if the battery/switch are 
> >moved to a new location... the animation still work.
>
>Two comments.  First, reading the SVG code, with smooth motion 
>animation
>
>and smooth attribute animation it already exceeds the baseline 
>requirements we have heard -- step animation -- from at least two 
>sources so far.
>
>Second, that level of immunity to editing ("goes from rectangle to
>polygon") is provided in your SVG example by indirect reference to a 
>named path within an animateMotion element (which is an SVG-specific 
>extension to SMIL 2.1, correct?).  Am I correct that this level of 
>sophistication is beyond what you support in your private WebCGM 
>animation subset for IsoDraw/IsoView?
>
>I haven't thought it through completely, but I'm unsure that you could 
>achieve that in WebCGM without embedding the animation elements 
>directly
>
>within the WebCGM instance.
>
>
> >Again, I'm not opposed to animation in CGM, but I very much favor a 
> >declarative approach than a DOM approach.
> >
> >Thoughts?
>
>I don't really disagree with anything you have said.  I think our 
>difficult task is to decide where we should set our sights, in the 
>spectrum from ZERO to full-SVG/SMIL-like.  There are levels of 
>possibilities:
>
>a.) nothing more in 2.1:  people will continue to do DOM animation with

>1.0 and 2.0, as M&L and as Stuart.
>b.) a little more help in 2.1 with a couple things that would simplify 
>DOM animation
>c.) a simple XCF-based set of animation declaration elements (in 
>addition or instead of #b).
>...
>d.) like circle.svg -- intra-WebCGM embedded animation declaration 
>elements, enabling much of the SMIL/SVG-like functional capability.
>
>We can't go to #d in a quick 2.1, and perhaps never -- not only is 
>there
>
>the risk that the vendors might not follow, but I'm not sure that I can

>envision this stuff intra-WebCGM, i.e., animation elements within the 
>metafile itself (like circle.svg).
>
>Whereas I can see "animate a picture" within the scope of WebCGM, I'm 
>not yet sure I can see "animated picture".  (If you know what I mean.)
>
>All for now,
>-Lofton.
>
>
> >-----Original Message-----
> >From: Lofton Henderson [mailto:lofton@rockynet.com]
> >Sent: Monday, October 01, 2007 6:10 PM
> >To: Galt, Stuart A; cgmo-webcgm@lists.oasis-open.org
> >Subject: Re: [cgmo-webcgm] Flow of electricity
> >
> >Stuart --
> >
> >Good stuff!  Again, we should be looking to put your examples (and 
> >anyone
> >else's) of 2.0 capabilities somewhere on the Web site.  So, aside 
> >from technical (and 2.1 rqts questions), there is the 
> >Education/Outreach
> >question:  when and where can we put these up and direct people to
>them?
> >
> >Technical questions...
> >
> >At 01:46 PM 9/28/2007 -0700, Galt, Stuart A wrote:
> > >[...]
> > >As I start making more complex images/applications I am finding
>myself
> > >wishing I had a either getStyleProperty() or removeStyleProperty()
> >
> >Is the "get" an inquiry function?  Do you actually want both "get" 
> >and "remove", or did you really mean "either...or"?
> >
> >Do you propose that these be added to the 2.1 wish list?
> >
> > >method
> > >(I realize that this is difficult to implement) and the ability to
>make
> >
> > >several DOM changes without waiting for a redraw between each one.
> >
> >I guess this has now been added to the 2.1 wish list.
> >
> >-Lofton.
> >
> >