Re: [cgmo-webcgm] Change Proposal: Object Behaviors

[Lofton Henderson <lofton@rockynet.com>]

Dieter (et al),

At 04:35 PM 11/15/2004 +0100, Dieter Weidenbrueck wrote:
> [...]
> here is a draft of a change proposal with regard to object 
> behaviors
> as an input to tomorrow's telecon.

Thanks for this thorough presentation.  I generally support your
ideas, with some caveats and suggestions.

The following is quoted from Section 2, about current object behaviors
(comments embedded):

> At present, there are two sections
> that describe the behaviors. [1] and
> [2]. Both sections suggest
> inconsistent behaviors:

I would warn against reading too much into
"inconsistent".  I think there is some sloppiness. 
But I would not read it as contradictory specifications. 
More...

View_Context according to [1]:

-       If view_context attribute exists on object: display viewcontext area and highlight the object.

-       If no view_context attribute exists on object: use highlight behavior

This omits to detail the two cases, presence and absence of a region (no
region -- highlight the geometry of the object; region -- highlight the
region), which detailing is done in [2].

View_Context according to [2]:

-       If view_context attribute exists on object: display viewcontext area (but nothing said about hightlighting)

This is an oversight.  Author probably assumed that highlighting the
object was obvious, because of [1].  Reason I think this:  The
above is the first bullet in a 3-bullet list, dealing with 3 cases: 
vc exists; no vc, but region; no vc, no region.  The 2nd and 3rd
cases specify what to highlight, and what is the view (zoom).  The
1st case doesn't explicitly, but combining it with [1]:  highlight
the geometry.

-       If no view_context attribute exists on object:

o       If region exists: display full view and highlight region

         o      If no region exists: move object into view AND go to full-picture view, highlight object’s primitives

Conclusion:  there are a couple omissions, but combining the
(missing) parts from [1] and [2] gives a complete and consistent
specification.  

Moving on to Section 3, about proposed object behaviors, I support your
general approach:

> I propose that we strictly separate
> navigation and highlighting, and that we add explicit keywords to do
> combinations of both.

However, I think we should try hard to not break 1.0 content for 2.0
applications.  Here some thoughts to that end...

-- Highlight and highlight_all are okay, as you say
"unchanged".  Keep the names, keep the
descriptions.

-- "View_context" is overloaded in 1.0.  So taking off
from your comment, "The names of the new behaviors may be chosen
differently...", I'd say that
we should change it to "zoom" in 2.0.  Reason:  you
always zoom to something, either the 'viewcontext' ApsAttr, or the
'region' ApsAttr, or the bounding box of the geometry of the
object.  Therefore your set of behaviors becomes:
* zoom
* highlight
* highlight_all
* zoom_all
* highlight_zoom
* highlight_zoom_all

I would put these six in a table by themselves.  I would then put
view_context in a separate 1-line table, and indicate that it is
deprecated.  It shall not appear in a 2.0 WebCGM instance.  A
2.0 viewer which encounters it in a 1.0 file shall treat it like: 
[...describe its behavior in terms of the 6 building blocks...]

Final suggestion:  define the defaults so that they align with the
1.0 defaults.  I.e., in the absence of any object behaviors, a 2.0
viewer should act like a 1.0 viewer.  I.e., if you take a 1.0 file,
change only its version (ProfileId to 2.0), then in a 2.0 viewer its
appearance should not change.

All for now,
-Lofton.