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

[Don Larson <dlarson@cgmlarson.com>]

Lofton,

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

Yes , I agree; it is complete and clear. As written I have no issues with it.

  > 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?
No, I  see no usefulness to viewers.

  > 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?

Yes, it would be useful.  It would enable me to keep this group of picture 
elements grouped when I read them in to my editor so they can be 
subsequently manipulated as a group.

  > 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