[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
Lofton, 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. 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. Rob -----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]