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


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]