RE: [cgmo-webcgm] clarification of 1.0 object behavior mapping

[Dieter Weidenbrück <dieter@itedo.com>]

All,

I saw that the people on the telecon last week have
discussed this before I was able to respond.
Nevertheless I want to do this.

See below,
Dieter 

> -----Original Message-----
> From: Lofton Henderson [mailto:lofton@rockynet.com] 
> Sent: Tuesday, March 14, 2006 9:16 PM
> To: Robert Orosz; cgmo-webcgm@lists.oasis-open.org
> 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.
Section 3.4 "WebCGM and the object element" clearly defines what the
initial state of the picture is, it is defined by the mapping (fit|fill)
and the halign and valign params.


> >
> >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).
I can't see this. As mentioned above, 3.4 defines the initial view,
then the newHighlight happens. Where is the ambiguity?

> 2.) The mapping specification (highlight -> newHighlight) 
> runs into that ambiguity.
Understood and agreed.


> 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).
No, I wouldn't warn. The user can easily combine navigation and
highlighting as desired, this is the precise purpose of separating
navigation and highlighting into separate keywords. Why an additional
warning?
It would sound a bit like
"Here are the keywords for navigation, and here are the ones for
highlighting. Please be aware of the fact that navigation keywords
will not trigger highlighting, and highlighting keywords will not
trigger navigation."
Sounds redundant to me.


> 
> 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.)
Yes.

Regards,
Dieter

> 
> -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.
> 
> 
>