Re[2]: [cgmo-webcgm] Draft Proposals

[Benoit Bezaire <benoit@itedo.com>]

Monday, November 15, 2004, 9:55:18 PM, Lofton wrote:
LH> Bravo!
Thanks.

LH> This is the first time that anyone has bother to write down all the details
LH> of a proposal, all of the effects, side effects, interactions, etc.

LH> There is too much for me to comment on all, but a couple of comments and
LH> questions are embedded...

LH> At 02:18 PM 11/15/2004 -0500, Benoit Bezaire wrote:
>>[...]
>>   *** A new 'grgroup' definition ***
>>   The application structure of type 'grgroup' is being proposed for
>>   WebCGM 2.0.  The addition of the 'grgroup' APS (or the existing
>>   'grobject) + static attribute) is needed to enhance interchange
>>   of WebCGM files between authoring tools.  The 'grobject' APS
>>   unfortunately has different implications (interactiveness) in
>>   various CGM profiles and is therefore not the ideal candidate for
>>   grouping graphical primitives.  The 'grgroup' APS is being proposed as
>>   a mechanism of choice for grouping graphical primitives in authoring
>>   tools.  Grouping various objects is a frequent user operations in
>>   all commonly used authoring tools (CGM based or not). By
>>   standardizing a grouping method, authoring tools will be able to
>>   more easily maintain the file structure intended by the user.

LH> This is important -- to explain what it is for.  On a scale of 0-10, here
LH> is how I rate the utility of grgroup in these "interchange" scenarios:

LH> 1.) round-tripping for a single authoring application:  10
LH> 2.) authoring tool to viewer:  0-1
This might be a bit low.  I believe Ulrich has a switch in his viewer
to work around this problem (ATA files flash all the time).  I'll let
Ulrich speak up on this (don't want to say things that aren't true).
But the bottom line is that if viewers need switches to control the
viewer behavior for various profiles of CGM files; there's a problem
somewhere!

LH> 3.) authoring tool A to authoring tool B:  2-3
I also think this is low, but it would be nice to hear from other tool
vendors on this.  I can say that with my previous employment, this
was critical.  Users get mad if the file structure is not maintained,
regardless of the file format (AI, PS, CGM, SVG, CDR etc...).

LH> So IMO grgroup it is virtually useless for interchanging anything 
LH> meaningful to viewers.  Question.  Does anyone see anything useful to
LH> viewers, that they cannot deduce trivially?

LH> My feeling is that it is low utility from application A to B -- B will only
LH> see there are grgroups, but not know what is their significance to A, so
LH> probably cannot use them "as A intended".
Tool A doesn't use them in any _special_ way.  Yes, they are not
'grobject' but that doesn't make them that special :-)  It's the classic
'Ctrl+G' operation, that's all.

LH> But that's just an opinion.  Question to authoring-tool vendors:
LH> if you got a WebCGM from someone else's authoring tool, would that
LH> be useful to you?  Could you make good use of it somehow?
It's not that they are useful to the tool. They are useful to the
user.  It's an important distinction.  If it took 100 polybeziers to
draw a bolt in tool A, but the polybeziers are within a group, so
clicking on one of the bezier selects the entire bolt... the user
_does_ expect the same behavior in another tool.  That is, not to
select a single bezier segment, but the entire bolt.

LH> That aside, I can accept that #1 is sufficient reason to have grgroup (or
LH> grobject+static).  And Ben's explanation is not bad.  However I would
LH> soften the statement, "is needed to enhance interchange of WebCGM files
LH> between authoring tools".  I don't think it adds anything to the 
LH> interchange.  But it is valuable to the author/authoring tool, that the
LH> WebCGM intended for interchange can preserve some structure and 
LH> organization important to the authoring tool.  (It is harmless to the
LH> interchange process, but IMO not very useful.)


>>   Apart from the APS ID, a 'grgroup' cannot have any other attributes.
>>   The 'visibility' attributes is also excluded.
>>
>>   The application structure 'grgroup' is meant to group basic
>>   graphical primitives; a frequent user operation. The content of a
>>   'grgroup' is however, not limited to graphical primitives.  The
>>   allowed content of a 'grobject' is the same as the one allowed for
>>   the 'grobject' application structure.

LH> s/grobject/grgroup/
Thanks.

>>   Like the other application structure types, the 'grgroup' supports
>>   inheritance (i.e., it is possible to make a 'grgroup' non-visible by
>>   inserting it within an object which support the 'visibility'
>>   attribute).
>>
>>   Unlike the application structures, the 'grgroup' is not interactive.
>>   It does not receive mouse events like other application structures.
>>   The content of a 'grgroup' can however be interactive if that
>>   content is a direct child of a 'grobject', 'para' or 'subpara'.

LH> Careful here.  As I read this and the event stuff, I *think* the following
LH> is true:  if the parent grobject captures the event, then its apsid is
LH> associated with the event.  Is that right?  If yes, then it seems odd to
LH> say that the grgroup is "interactive".  (Or is the apsid "closest to the
LH> leaf", i.e., the grgroup's apsid, the one that is associated?).  I guess
LH> you're saying that the grgroup, if otherwise eligible to be the event
LH> target, bubbles it on up?
I need to review these two paragraphs.

LH> (Out of time...good job!)

LH> -Lofton.

-- 
 Benoit   mailto:benoit@itedo.com