Draft Proposals

[Benoit Bezaire <benoit@itedo.com>]

Hi all,

Here's a writeup on some of the things we talked about in Houston.
This is a draft proposal so please send feedback.  If time
permitting, we can talk about during Tuesday's telecon.

Regarding the 'grgroup' or 'grobject' + static proposal... in Houston
we mostly talked about 'grobject' + static, but my personal opinion is
that 'grgroup' is cleaner.  If the group disagrees with me, I can
certainly change the wording and go with the 'grobject' + static
approach instead; I don't have a strong opinion on this.

Cheers,

  -------------------------------------------------------------------

  *** 'interactivity' attribute ***
  Value: on | off
  Initial: on
  Applies to: 'layer', 'grobject', 'para' and 'subpara'.
  Inherited: yes

  The 'interactivity' attribute indicates if an object may receive
  mouse events.  When the 'interactivity' of an object is set to off,
  events for this object are disabled.  This has the effect of
  disabling event handlers, cursor changes, highlighting, screentip
  and hyperlinking for the given node and its descendant.  An object
  that is the target of a link always responds to highlighting,
  regardless of its 'interactivity' attribute value.
  
  -------------------------------------------------------------------
  
  *** 'visibility' attribute ***
  Value: on | off
  Initial: on
  Applies to: 'layer', 'grobject', 'para', 'subpara'.
  Inherited: yes

  The 'visibility' attribute indicates if an object is visible or not.
  A non-visible object behaves like a non-interactive object (i.e.,
  it cannot be clicked or highlighted).  This does not imply that the
  'interactivity' attribute is changed to off; but simply that the
  user agent must not respond to mouse events.
  
  --------------------------------------------------------------------

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

  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.

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