[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[2]: [cgmo-webcgm] ISSUE: does the 'highlight' object behavior revert to full-picture view?
Hi, I agree that the "_replace" wording should be reviewed. What's needed to resolve this issue? BTW, I don't see replace as being the same thing as reloading. As we all know... all Web browsers cache as much information as possible. In HTML, linking from a Table Of Content to a specific chapter doesn't reload the entire HTML, browsers optimize for the case where the starting resource and ending resource are the same. In SVG... you can link to 'view' elements, user agents don't reload the entire SVG file when such an operation happens. 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." Is that breaking existing content? I don't think so. -- 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. >> >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]