OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[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]