Re: [cgmo-webcgm] Draft Proposals

[Lofton Henderson <lofton@rockynet.com>]

Bravo!

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

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

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.

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

1.) round-tripping for a single authoring application:  10
2.) authoring tool to viewer:  0-1
3.) authoring tool A to authoring tool B:  2-3

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

My feeling is that it is low utility from application A to B -- B will only 
see there are grgroups, but not know what is their significance to A, so 
probably cannot use them "as A intended".  But that's just an 
opinion.  Question to authoring-tool vendors:  if you got a WebCGM from 
someone else's authoring tool, would that be useful to you?  Could you make 
good use of it somehow?

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

s/grobject/grgroup/


>   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'.

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

(Out of time...good job!)

-Lofton.

>   Additionally, if a mouse event is triggered on the geometry of a
>   'grgroup', an ancestor node may respond to the event if that
>   ancestor node is of type 'grobject', 'para' and 'subpara'.  See the
>   Event interface for more information regarding mouse events.
>
>   ---------------------------------------------------------------------
>
>   *** Event Interface (add this to the interface section) ***
>   There exists three levels of interactivity in WebCGM:
>   - User-initiated actions such as a mouse click can be captured by
>   the host environment and execute scripts.
>   - The user can initiate hyperlinks to Web pages or other WebCGM
>   illustrations.
>   - User agent, users are able to zoom into and pan around WebCGM
>   content.
>
>   When a mouse event occurs, the WebCGM user agent determines the
>   target element of a mouse event. The target element is the topmost
>   graphics element whose relevant graphical content is under the
>   mouse at the time of the event. An application structure of type
>   'grgroup' cannot be a target of a mouse event.  Instead, if the
>   mouse pointer was over a 'grgroup' when the event occurred; its
>   closest ancestor element of type 'layer', 'grobject', 'para' or
>   'subpara' will be designated as the target element. When an element
>   is not displayed (i.e., 'visibility' attribute is set to off) or
>   made non-interactive (i.e., 'interactivity' attribute is set to
>   off), that element cannot be the target of mouse events.
>
>   The event is either initially dispatched to the target element, to
>   the Picture element or not dispatched depending on the following:
>
>   -If there are no graphics elements whose relevant graphics content is
>   under the mouse (i.e., there is no target element), the event is not
>   dispatched.
>   -Otherwise, there is a target element. If there is an event handler
>   at the Picture level with event capturing for the given event, then
>   the event is dispatched to the Picture.
>   -Otherwise, if the target element has an appropriate event handler
>   for the given event, the event is dispatched to the target element.
>   -Otherwise, the Picture element is checked to see if it has an
>   appropriate event handler. The event is dispatched to the Picture if
>   one is found.
>   -Otherwise, the event is discarded.
>
>   The processing order for mouse events is as follows:
>
>   -Events handlers assigned to a WebCGMPicture get the event first via
>   the potential event bubbling. If none of the activation event
>   handlers take an explicit action (by invoking the preventDefault()
>   WebCGM DOM method) to prevent further processing of the given event,
>   then the event is passed on for:
>   -Cursor change, screentip and hyperlink processing. If a hyperlink
>   is invoked in response to a user interface event, the hyperlink
>   typically will disable further activation event processing (e.g.,
>   hyperlink to another Web page). If link processing does not disable
>   further processing of the given event, then the event is passed on
>   for:
>   -Document-wide event processing, such as user agent facilities to
>   allow zooming and panning of a WebCGM document.
>
>   ---------------------------------------------------------------------
>
>   Regards,
>
>--
>  Benoit                 mailto:benoit@itedo.com