[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cgmo-webcgm] clarification of 1.0 object behavior mapping
At 01:14 PM 3/8/2006 -0700, Robert Orosz wrote: >[...] >You raise some good points. Section 3.1.2.4.1 is unambiguous only for >intra-CGM linking. It becomes ambiguous for either inter CGM-CGM or >HTML-CGM links because the viewer must perform a navigation to load the new >picture. If there is no navigation keyword present in the object behavior, >then the viewer has two choices as to the type of navigation to perform. >So, I agree that "newHighlight" alone is unnecessarily ambiguous when used >in a context that forces a load of a new picture. This ambiguity could >arise in a pure 2.0 context in addition to the 1.0 mapping scenario that you >describe. The "full+newHighlight" object behavior is probably what is >intended here. That is what the just-updated 1.0 test cases show as correct result (-objHighlight- and -objHighlightAll-). It is the defined behavior of the 1.0 keywords. It is also how I would interpret the "no navigation" prescription from the table -- open the picture, and do nothing more. >We should have specified here what the default navigation >state of a picture is when it is loaded via a URI fragment containing an >object behavior without a navigation keyword. > >As far as mapping old 1.0 object behaviors, I agree with your point that >mapping the bare 2.0 "newHighlight" introduces an ambiguity. The ambiguity >could be resolved by specifying a default navigation state as described >above, or changing the specification of the mapping of old 1.0 object >behaviors to 2.0 behaviors that include both a navigation and a highlight >keyword. As you note, there are two problems here: 1.) The new "newHighlight" behavior is ambiguous when the link requires opening new content (CGM-CGM or HTML-CGM). 2.) The mapping specification (highlight -> newHighlight) runs into that ambiguity. For new content (#1), it is possible for the user to avoid the ambiguous situation. Therefore, the spec could warn "don't do this". That would be the *minimal* change to current 2.0 text. Defining the default navigation state for the bare keywords is a cleaner solution, but it's also more of a technical change and will require getting consensus that issue (the default navigation for newHighlight). For old content (#2), the ambiguity should be removed (since the user can't avoid it). The way to do that, preserving the old 1.0 behaviors, is to correct the mapping: full+newHighlight. (1.0 was unambiguous about that, and full+newHighlight is exactly the 1.0 behavior.) -Lofton. > >-----Original Message----- >From: Lofton Henderson [mailto:lofton@rockynet.com] >Sent: Tuesday, March 07, 2006 3:14 PM >To: cgmo-webcgm@lists.oasis-open.org >Subject: [cgmo-webcgm] clarification of 1.0 object behavior mapping > > >All -- > >Please give your feedback... > >I'm having a little trouble interpreting, for test suite construction, what >we wrote in 3.1.2.4.1. About the three old 1.0 object behaviors, the >normative specification is: > > > * view_context maps to zoom+newHighlight > > * highlight maps to newHighlight > > * highlight_all maps to newHighlight > >Now we had some trouble about the mapping of view_context, because it >doesn't have any (simple) exact equivalent in 2.0. And that was the root >of the recent go-around about the default behavior (which was view_context >in 1.0). > >But highlight and highlight_all *do* have an exact equivalent, because 1.0 >says, "The resulting view is a full-picture view, not a zoomed view." So >the exact equivalent of the 1.0 behavior for highlight and highlight_all >is: full+newHighlight. > >The test "behavior-objHighlight-BE-05" has an HTML-to-CGM link. The >3.1.2.4.1 table says that 'newHighlight' alone has *no navigation*, which >means that the H2C link should result in a highlighted full picture view. > >Does everyone agree that 'newHighlight' alone is unnecessarily ambiguous >and should be "full+newHighlight"? > >More observations... > >Bare 'newHighlight', without a navigation term (full or zoom) is only >useful for cumulative navigations (introduced and clarified in 2.0) within >the same picture. Cumulative object behaviors are not applicable to H2C >links, and in any case 1.0 had no clear concept of cumulative object >behaviors (in fact, the "full-picture view" in the 1.0 'highlight' >definition prevents accumulation). So mapping to the bare 2.0 >'newHighlight' behavior corresponds to no 1.0 functional purpose, and in >fact introduces an ambiguity whose solution is only hinted at by the lack >of an "X" in the Navigation column of the 3.1.2.4.1 table. (And by reading >the 1.0 specification.) > >I'd like definitive clarification of this, before uploading the revised >'behavior-...-BE-05", BE-06, and BE-07 files. (Actually, BE-07 is about >view_context, and that is defined as mapping to zoom+newHighlight, which is >unambiguous.) > >Please comment. > >-Lofton.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]