RE: [cgmo-webcgm] ISSUE: does the 'highlight' object behavior revert to full-picture view?

[Lofton Henderson <lofton@rockynet.com>]

At 11:22 AM 6/14/2005 +0200, =?us-ascii?Q?Dieter__Weidenbruck?=
wrote:
> [...]
> you are right, and we should change the default.

Actually, my preferred solution would be to clarify the _replace behavior:  for a C2C link, that goes from one object in a picture to another object in the same picture, if the picBehavior is _replace (either by default or explicit setting), then the viewer SHALL NOT reload the picture, but rather shall preserve the existing view state and apply any new objBehaviors.

More below...

 

The viewer shall replace the current picture by the designated picture in the same rectangular area in the same frame or window as the picture which refers to this target. This is the default behavior for CGM-to-CGM links.

The last sentence here should be deleted probably. Somehow we need to change the behavior compared to WebCGM 1.0 to accomplish several things:
 
1. LinkURIs
CGM to CGM linkURIs like
#name(myObj,move)                simple navigation to another object
#xcf(myXCF.xml)                    load and apply this companion file
 
2. DOM calls
(assume a cgm is loaded and displayed)
cgmDoc.src = ""#name(myObj,move)"
cgmDoc.src = ""#xcf(myXCF.xml)"
 
This is especially important to be able to load XML companion files in a sequence, e.g.
- myScreentips.xml
- myLinks.xml
- myConfiguration.xml
 
Suggestion:
If a picture behavior is explicitely stated, it must be used
If no picture behavior is stated, and the nature of the link doesn't require a reload of the file, don't use a picture behavior.
 
It is absolutely mandatory to resolve this for 2.0, because it would kill
both the (strongly required) new object behaviors, and the cascading companion files.

I have no problem that we fix it.  It seems to be what at least some people had in mind, in designing and approving the objBehavior controls. 

I'd like to hear from more implementors:  do you support that interpretation of C2C links?

Finally, let's take a little care that we get it right and define it completely.  Above I stated a set of conditions that it should apply to:  "for a C2C link, that goes from one object in a picture to another object in the same picture, if the picBehavior is _replace..."

1.) it would NOT apply to HTML-to-CGM links, right? 
2.) it would NOT apply to C2C links, where the link went from one CGM file to another different CGM file, right?  (Several sub-cases depending on picBehavior -- but recommend to treat them all the same.)
3.) it would not apply to links that have behaviors other than _replace (i.e., _blank, target, etc) picBehavior, right?
4.) for picBehavior _self, and things like _parent that turns out to be the same as _self if there is no parent, would it apply?  (I recommend we restrict it to _replace -- whether defaulted or explicitly set -- which makes it clean, clear, and simple where the cumulative behavior should apply.)

Example of #1: 
-----
Imagine a HTML parts list, with text items 1, 2, 3, 4, ...

<a href=""parts.cgm#part1>1.)" Reverse screw, serial nbr  123456</a>
...
<a href=""parts.cgm#part4>4.)" Wingnut, serial nbr  24680</a>

If the user clicks item 1, and then goes away and does other stuff, and then clicks #4 -- there should be no consideration of preserving views (for any of the several possible HTML 4.01 TARGET behavior keywords, which btw don't include _replace).

Regards,
-Lofton.

-----Original Message-----

From: Lofton Henderson [mailto:lofton@rockynet.com]

Sent: Friday, June 10, 2005 5:32 PM

To: dieter@itedo.com; cgmo-webcgm@lists.oasis-open.org

Subject: RE: [cgmo-webcgm] ISSUE: does the 'highlight' object behavior revert to full-picture view?

Disclaimer:  I don't feel strongly about how we resolve the objBehavior issue, as long as:  1.) it's not broken, and 2.) the users are happy with it, and  3.) the users are happy with it.  We will need to change existing 1.0 test cases (which test the old 3 behaviors), and implementors will have to implement the new 2.0 stuff (if we don't have 2 implementations, it gets tossed, at least in W3C context).

New wrinkle:  We have been ignoring picBehavior....

If there is an explicit picBehavior, then 3.1.2.2 says that the picture is reloaded anyway.  So the current view or objBehavior is wiped out.  Let's look at some examples.

Example 1:  Clearly, _blank (new window) would do this. 

Example 2:  Clearly any link from outside, e.g., from HTML, would contain the CGM filename and that would (I believe) lead to (re-)loading the CGM, even if it were the same CGM as the viewer previously loaded.

Example 3:  What about an intra-CGM link?  I.e., myCGM.cgm is already loaded and viewed.  myObj1 contains a 'linkuri' to myObj2, as follows:  #pictseqno(1, _replace).objid(myObj2, highlight_move).  Does 3.1.2.2 imply that the picture is reloaded?  I believe it does imply that (without judging whether it should or not).

Example 4:  Like example 3, but:  #objid(myObj2, highlight_move).  What now?  3.1.2.2 says about _replace:

The viewer shall replace the current picture by the designated picture in the same rectangular area in the same frame or window as the picture which refers to this target. This is the default behavior for CGM-to-CGM links.

In other words, according to as 3.1.2.2 is currently written, because of default, this is the same as Example 3:  the viewer wipes out and replaces the existing picture.  It says nothing about preserving any current view state, if the CGM is in fact the same. 

So as I read the current text of 3.1.2.2, all of the "relative" objBehaviors like "move" are actually moot.

Something is broken:  either we need to throw away some of the objBehaviors, or in 3.1.2.2 we need to special-case the case of same-CGM, picBehavior "_replace" (explicit?  default?  both?).

Regards,
Lofton.

At 08:32 AM 6/10/2005 +0200, =?us-ascii?Q?Dieter__Weidenbruck?= wrote:

Hi Lofton,

see my comments inline.

> -----Original Message-----
> From: Lofton Henderson [mailto:lofton@rockynet.com]
> Sent: Friday, June 10, 2005 12:15 AM
> To: cgmo-webcgm@lists.oasis-open.org
> Subject: [cgmo-webcgm] ISSUE: does the 'highlight' object behavior
> revert to full-picture view?
>
>
>  From Ben's comments and Dieter's comments:
> http://lists.oasis-open.org/archives/cgmo-webcgm/200504/msg00017.html
> http://lists.oasis-open.org/archives/cgmo-webcgm/200506/msg00021.html
>
> At 04:34 PM 4/21/2005 -0400, Benoit Bezaire wrote:
> >   - When we say: The resulting view is a full-picture view, not a
> >   zoomed view... Do we zoom out even if the target rectangle already
> >   fits in the viewer's viewport?
>
> At 04:34 PM 4/21/2005 -0400, Dieter wrote:
> >3.1.2.4.3
> >The definition of highlight is in contradiction with the table in
> >3.1.2.4.1. The table suggests that highlighting does not cause
> navigation.
> >Suggestion: Delete "The resulting view is a full-picture view, not a
> >zoomed view."
>
> The present descriptions of 'highlight' object behavior says that it
> reverts to a full picture view.  The table, on the other hand,
> says that it
> has no navigation effects.  Dieter proposes that the table is
> correct, and
> the text is wrong.
>
> If Dieter's view is correct, then the set of object behaviors is
> broken --
> it has these two problems at least:
>
> i.) No way to get full-picture view.  Once the view has changed from full
> picture, e.g., the user pans and zooms an initial full-picture view with
> the viewer controls, there is no object behavior that can get you
> back to a
> full picture view.  (If all view changing is removed from 'highlight', a
> 'full' keyword is needed to fix this.)
Understood and agreed. In general navigation to a full view is always
possible by using the URL without any fragment, however, it is a good idea
to add a "full" keyword.

>
> ii.) The 'highlight' keyword is useless.  When a program or an
> XCF issues a
> 'highlight' behavior, it has no way of knowing what is the present
> view.  Another DOM or WebCGM or XCF transaction may have changed it.  Or
> the user may have panned/zoomed the picture with viewer controls.  It is
> unknowable, in general, whether the target to be highlighted is
> visible.  Therefore, no one would risk using 'highlight' (or
> 'highlight_all').  Only 'move_highlight' or 'zoom_highlight' have any
> usefulness.
It is not useless in my eyes, it becomes much more powerful now. So far,
users rarely used this keyword because of the unwanted navigation effects.
Combinations with navigation are well defined now, so highlight is reserved
for the cases where the implementor well knows what he is doing.

>
> Alternative 1.  no change, 'highlight' is a full-picture
> view.  (Editorially fix any contradictions.)
> Alternative 2.  Highlight does no navigation, leave the problems
> i. and ii.
> broken as described above.
> Alternative 3.  Highlight does no navigation, remove 'highlight' from
> table, add 'full', 'full_highlight', and 'full_highlight_all' to
> table (12
> rows in the table.)

Suggestion:
Add alternative 4:
Alternative 4. Highlight does no navigation, add 'full', 'full_highlight',
and 'full_highlight_all'.
NOTE: combinations like 'full_highlight_zoom" etc are not needed of course,
so it is 3 new entries.

I vote for 4.


>
> (Alternative 4.  Revert to WebCGM 1.0 definition.)
>
> RECOMMENDATION.  Alternative 1.
>
> -Lofton.
>
>
>