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

[Lofton Henderson <lofton@rockynet.com>]

[Others (than DW, BB, and me), please below, last comment...]

At 10:20 AM 6/14/2005 -0400, Benoit Bezaire wrote:
>[...]
>   Would this wording be more appropriate, "_replace":
>   "The viewer shall display the designated CGM picture in the same
>   rectangular area in the same frame as the picture which refers to
>   this target. If the ending resource is the same as the linking
>   resource, the viewer does not reload the resource."

I think you're saying, more elegantly, the same thing I tried to say 
(C2C-link + same-CGM-file + _replace), and with which Dieter agreed also.

>
>   Is that breaking existing content? I don't think so.

I agree.

It would be good for some others -- users and/or vendors -- to speak up now 
if they think otherwise.

Cheers,
-Lofton.


>--
>  Benoit   mailto:benoit@itedo.com
>
>
>Tuesday, June 14, 2005, 5:22:44 AM, Dieter wrote:
>
>DW> Lofton,
>DW>
>DW> you are right, and we should change the default.
>DW>
>
>DW> The viewer shall replace the current picture by the
>DW> designated picture     in the same rectangular area in the same
>DW> frame or window as the picture     which refers to this target.
>DW> This is the default behavior for CGM-to-CGM     links.
>
>DW> The last sentence here should be deleted probably. Somehow we
>DW> need to change the behavior compared to WebCGM 1.0 to accomplish
>DW> several things:
>DW>
>DW> 1. LinkURIs
>DW> CGM to CGM linkURIs like
>DW> #name(myObj,move)                simple navigation to another object
>DW> #xcf(myXCF.xml)                    load and apply this companion file
>DW>
>DW> 2. DOM calls
>DW> (assume a cgm is loaded and displayed)
>DW> cgmDoc.src = "#name(myObj,move)"
>DW> cgmDoc.src = "#xcf(myXCF.xml)"
>DW>
>DW> This is especially important to be able to load XML companion files in 
>a sequence, e.g.
>DW> - myScreentips.xml
>DW> - myLinks.xml
>DW> - myConfiguration.xml
>DW>
>DW> Suggestion:
>DW> If a picture behavior is explicitely stated, it must be used
>DW> If no picture behavior is stated, and the nature of the link
>DW> doesn't require a reload of the file, don't use a picture behavior.
>DW>
>DW> It is absolutely mandatory to resolve this for 2.0, because it would kill
>DW> both the (strongly required) new object behaviors, and the cascading 
>companion files.
>DW>
>DW>
>DW> Regards,
>DW> Dieter
>DW>
>
>
>
>
>DW> -----Original Message-----
>DW> From: Lofton Henderson   [mailto:lofton@rockynet.com]
>DW> Sent: Friday, June 10, 2005 5:32   PM
>DW> To: dieter@itedo.com;   cgmo-webcgm@lists.oasis-open.org
>DW> Subject: RE: [cgmo-webcgm] ISSUE:   does the 'highlight'
>DW> object behavior revert to full-picture   view?
>
>
>DW> Disclaimer:  I don't feel strongly about how we   resolve the
>DW> objBehavior issue, as long as:  1.) it's not broken, and 2.)   the
>DW> users are happy with it, and  3.) the users are happy with it.
>DW> We will need to change existing 1.0 test cases (which test the old
>DW> 3   behaviors), and implementors will have to implement the new
>DW> 2.0 stuff (if we   don't have 2 implementations, it gets tossed,
>DW> at least in W3C   context).
>
>DW> New wrinkle:  We have been ignoring   picBehavior....
>
>DW> If there is an explicit picBehavior, then 3.1.2.2 says   that
>DW> the picture is reloaded anyway.  So the current view or
>DW> objBehavior   is wiped out.  Let's look at some examples.
>
>DW> Example 1:    Clearly, _blank (new window) would do this.
>DW> Example 2:  Clearly   any link from outside, e.g., from HTML,
>DW> would contain the CGM filename and   that would (I believe) lead
>DW> to (re-)loading the CGM, even if it were the same   CGM as the
>DW> viewer previously loaded.
>
>DW> Example 3:  What about an   intra-CGM link?  I.e., myCGM.cgm
>DW> is already loaded and viewed.    myObj1 contains a 'linkuri' to
>DW> myObj2, as follows:  #pictseqno(1,   _replace).objid(myObj2,
>DW> highlight_move).  Does 3.1.2.2 imply that the   picture is
>DW> reloaded?  I believe it does imply that (without judging   whether
>DW> it should or not).
>
>DW> Example 4:  Like example 3, but:    #objid(myObj2,
>DW> highlight_move).  What now?  3.1.2.2 says about   _replace:
>
>
>
>DW> The viewer shall replace the current picture by the
>DW> designated picture       in the same rectangular area in the same
>DW> frame or window as the picture       which refers to this target.
>DW> This is the default behavior for CGM-to-CGM       links.
>
>
>
>
>
>
>
>
>
>DW> In other words, according to as 3.1.2.2 is currently written,
>DW> because of default, this is the same as Example 3:  the viewer
>DW> wipes out   and replaces the existing picture.  It says nothing
>DW> about preserving any   current view state, if the CGM is in fact
>DW> the same.
>
>DW> So as I read   the current text of 3.1.2.2, all of the
>DW> "relative" objBehaviors like "move"   are actually moot.
>
>DW> Something is broken:  either we need to throw   away some of
>DW> the objBehaviors, or in 3.1.2.2 we need to special-case the case
>DW> of same-CGM, picBehavior "_replace" (explicit?  default?    both?).
>
>DW> Regards,
>DW> Lofton.
>
>DW> At 08:32 AM 6/10/2005 +0200,
>DW> =?us-ascii?Q?Dieter__Weidenbruck?= wrote:
>
>DW> Hi Lofton,
>
>DW> 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.)
>DW> Understood     and agreed. In general navigation to a full view is always
>DW> possible by     using the URL without any fragment, however, it is a 
>good idea
>DW> 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.
>DW> It is not useless in my     eyes, it becomes much more powerful now. 
>So far,
>DW> users rarely used this     keyword because of the unwanted navigation 
>effects.
>DW> Combinations with     navigation are well defined now, so highlight is 
>reserved
>DW> 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.)
>
>DW> Suggestion:
>DW> Add alternative     4:
>DW> Alternative 4. Highlight does no navigation, add 
>'full',     'full_highlight',
>DW> and 'full_highlight_all'.
>DW> NOTE: combinations like     'full_highlight_zoom" etc are not needed 
>of course,
>DW> so it is 3 new     entries.
>
>DW> I vote for 4.
>
>
> >>
> >> (Alternative 4.      Revert to WebCGM 1.0 definition.)
> >>
> >> RECOMMENDATION.      Alternative 1.
> >>
> >> -Lofton.
> >>
> >>
> >>