Re: [cgmo-webcgm] RE: Transform Draft

[Lofton Henderson <lofton@rockynet.com>]

Comments about one question that Benoit asked, on the draft's packaging
of the transform functions...

At 12:18 PM 3/10/2008 -0400, Bezaire, Benoit wrote:
> Thanks
> for the draft Ulrich.
>  
> Lofton, how precise do we have
> to be for the first publication?
>  
> Some quick
> comments:
> - I don't know if the IDL
> definition supports function overloading (i.e., multiple definition of
> the same function name, ex: rotate). We may have to offer two rotation
> functions.
> - The 1) section should link
> back to the NVDC section.
> - I think the 'replace'
> parameter should be a keyword instead of a boolean, ex: add |
> replace.
> - Unfortunately, I do not
> understand the get/setTransformSP() functions. Could someone provide an
> example on how this will be used?

Although there is an excellent collection of material in the draft, I
also have some problems understanding some details about the IDL that is
proposed for the CD text -- like the get/setTransformSP()
functions.

In TC discussions and my functional summary of them, we (or at least I)
have used "setTransformSP()" as a hypothetical single catch-all
method into which all of our transform functionality was embedded. 
It would support specifications in the forms of:  general transform
matrix; scale transform; translate transform; rotate 
transform..

I did not mean to confuse and imply that it MUST be packaged that way,
and in fact that might not be the best idea (it could be complex). 
It was the task of the draft to chose how all of the functionality would
be designed and packaged for the interface.  A single
setTransformSP() method might be a possibility.  Or multiple
methods, each implementing an individual component (scale, translate, ...
, matrix).  Or some hybrid.

The draft has a hybrid, but I don't understand what is setTransformSP(),
which in my understanding was the catch-all for all of the
transform-setting capability.

Another unclear detail.  I have been using "convenience"
(or "convenience component") differently.  I have been
using it in association with a transform component like
"scale", "rotate", etc., which would have parameters
like scale factors, rotation angles, etc.  (As opposed to a general
transform matrix specification, into which one would have to compute the
matrix entries for, e.g., the scale operation.)

The draft seems to associate "convenience" rather with the
ability to specify a reference point for a component like
"rotate".  So in the draft there are two flavors of
rotate:  the default about the origin, or the
"convenience" where you can specify the reference point. 
(Whereas, in my terminology, the "convenience" is the rotate
method itself.)

We need to sort this stuff some more by end of Wednesday telecon,
sufficient to put something into 1st CD text.

-Lofton.
(Mostly away from email till Wednesday morning.)

- Shouldn't transforms be allowed on grobject, para, subpara and layer(?).
- With the XCF markup, XML doesn't allow us to say:
<grobject apsid="level-1-obj" translate="5 10" scale="2" />
elements can have an order, but not attributes. We will need to use a syntax similar to SVG's.
 
Regards,
Ben
 

---

From: Ulrich Laesche [mailto:laesche@ereviewonline.de]
Sent: Monday, March 10, 2008 9:50 AM
To: 'Cruikshank, David W'; stuart.a.galt@boeing.com; lofton@rockynet.com
Cc: dlarson@cgmlarson.com; forrest@sdicgm.com; franck.duluc@airbus.com; Bezaire, Benoit; Weidenbrueck, Dieter
Subject: WG: Transform Draft

All,

 

Attached is the discussion I had with Lofton over the weekend regarding the transform spec.  ***_draft4 is what Lofton already had a look at, updates*** is the remaining stuff including the table.  We can also remove the bounding box sentence.  It’s a leftover from previous drafts but not needed anymore.

 

Thanks and regards

Ulrich

 

 

-----Ursprüngliche Nachricht-----
Von: Lofton Henderson [mailto:lofton@rockynet.com]
Gesendet: Samstag, 8. März 2008 23:58
An: Ulrich Laesche
Betreff: Re: Transform Draft

 

Hi Ulrich,

This is an excellent piece of work.  Please congratulate Airat.

If anything, it is my initial sense that it is might more than we need, particularly the presence of both variants (around origin, and around specified point) for the convenience functions scale, rotate, translate.

There are also some statements that I need to think about -- don't understand on first reading.  E.g., the 1st paragraph of "General remarks", about the need to specify a bounding box via some API.

NEXT STEP:  I think you should get this to the TC as soon as possible.  There are some things that we need to discuss and resolve Wednesday, before I attempt to implement the stuff in the 2.1 draft.  These are complicated technical questions and I don't want to prejudge the answers.

At 11:16 AM 3/8/2008 +0100, Ulrich Laesche wrote:


Hi Lofton,
 
Attached you will find the text for the transform functions.  The text is not structured as in your WebCGM 2.1 draft as we don t know what you want to put into chapter 5.4.4.  It appears as if more than half of the text can go there.


I agree.  I will try to put most of the text there, with references to it.



Airat will still work on the XCF chapter 4 today.  In addition, in his submission he is referring to a Transformation Style Properties Table in accordance with Stuart s text, but I don t see it.  I will thus ask him to prepare one.  If you see topics missing (for example, I find no mentioning on the inheritance or child node behavior issues) please tell him.  Airat should also be available tomorrow so that he can prepare an updated delivery on Sunday evening (PST).


He can put XCF into a separate document, if easier.



Airat also told me that he put the TransformSP functions at the picture interface (as in chapter 5.7.5) while I mentioned we would put them at the APS interface.  I trust Airat here.


Okay.  That is another topic for the TC to discuss.

Thanks,
-Lofton.



Thanks and regards
Ulrich