RE: [cgmo-webcgm] 1.0 tests modified for 2.0

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

Lofton,

I can see your point, however

- we considered the 1.0 "default" behavior (full+highlight) to be a flaw
- we considered zoom+highlight the much more logical thing to do if
  navigation to an object is desired

BTW, IsoView NEVER did it "right", we always used zoom+highlight. This is
certainly not a reason to do it this way, however, given the widespread
use of our viewer not too many customers will be surprised by a change
as described, just the opposite: if we would change the IsoView behavior,
it would certainly puzzle our users, as they would loose the only way
to navigate to an object if no explicit viewcontext attr is defined on the
objects.

Dieter 

> -----Original Message-----
> From: Lofton Henderson [mailto:lofton@rockynet.com] 
> Sent: Monday, February 13, 2006 9:44 PM
> To: dieter@itedo.com; cgmo-webcgm@lists.oasis-open.org
> Subject: RE: [cgmo-webcgm] 1.0 tests modified for 2.0
> 
> At 08:46 AM 2/13/2006 +0100, Dieter  Weidenbrück wrote:
> > > -----Original Message-----
> > > From: Lofton Henderson [mailto:lofton@rockynet.com]
> > > Sent: Sunday, February 12, 2006 11:09 PM
> > > To: cgmo-webcgm@lists.oasis-open.org
> > > Subject: [cgmo-webcgm] 1.0 tests modified for 2.0
> > >
> > > Information, and QUESTION/ISSUE (for email and for next 
> telecon)...
> > >
> > > On FTS:  webcgm20-ts-20060212.zip
> > >
> > > I have started modifying the 1.0 (rel-1.1) dynamic tests, for 2.0 
> > > correctness, according to the assessment I sent a while 
> ago.  I will 
> > > keep doing this, and periodically put up new zip files.
> > >
> > > In this batch, changed tests are:
> > > * linking-selectID-BE-05
> > > * linking-selectName-BE-06
> > > * linking-anyURI-BE-07
> > >
> > > You can view them by opening the IntroPage.html and 
> navigating from 
> > > there.
> > >
> > > These three tests have something in common:  they have navigation 
> > > (links) to objects, but no specified object behaviors.  Therefore 
> > > they use the default object behavior.
> > > We changed the default object behavior for 2.0.  In 1.0, it was 
> > > effectively zoom+newHighlight (with a small wrinkle about 
> > > presence/absence of a 'viewcontext' ApsAttr on the target).
> > >
> > > Therefore you will see this:
> > >
> > > 1.) a 1.0 viewer showing the 1.0 file (in the 1.0 Test 
> Suite) should 
> > > give unzoomed view, highlighted object.
> >yes
> > >
> > > 2.) a 2.0 viewer showing the 2.0 file should give zoomed view, 
> > > highlighted object.
> >yes
> > >
> > > 3.) QUESTION.  what about a 2.0 viewer on the 1.0 file?
> > > Should it detect the version of the CGM (target) and do #1 or
> > > #2 accordingly?
> >We defined a mapping for 2.0 viewers for 1.0 behaviors. Once the 
> >behaviors got mapped, the viewer needs to show the correct 
> behavior for 
> >the 2.0 behaviors.
> 
> Yes, the 1.0 default is 'view_context', which 2.0 (CS) says to map to 
> zoom+newHighlight, regardless of the attributes of the target 
> object.  
> zoom+I'm
> going to question whether we goofed here...
> 
> The 1.0 'view_context' object behavior is this:
> a.) zoom+newHighlight if there is a 'viewcontext' ApsAttr on 
> the target object;
> b.) full+newHighlight if not.
> 
> I would be tempted to argue that, in real-world 1.0 content, 
> there will be many more default cases of type #b (no 
> 'viewcontext' ApsAttr present) than 
> type #a, which is the single default we chose for 2.0.   From 
> a standpoint 
> of user-friendliness, it would seem better not to introduce a 
> dramatic viewing change to what I guess to be the 
> preponderance of WebCGM 1.0 content in the real world.
> 
> Reinforcing this, the default cases in the 1.0 test suite 
> don't have 'viewcontext' ApsAttr present.  I'm questioning 
> the wisdom of a specification that is not actually necessary 
> and that forces a change of behavior by all conforming 2.0 
> viewers on virtually all default cases in the test suite, and 
> (IMO) most default cases in the real world.
> 
> Remind me, why did we not simply copy this behavior (a plus 
> b) for the 2.0 default?  All 1.0 viewers could do it, with no 
> changes.  It is not as simple to write down as a single value 
> ...  but it's already implemented!.
> 
> It was not until I started working on the test suite that the 
> 2.0 default began to bother me (this is the value of a TS, 
> and it would have been nice if we had had the resources to 
> upgrade it concurrently with the spec).  About 1/4 of the 
> tests are affected.
> 
> Bottom line -- I can't imagine 1.0 users being very happy, 
> when their vendor upgrades their viewer to 2.0, that all of 
> their 1.0 content starts behaving differently.
> 
> Regards,
> -Lofton.
> 
> 
> 
>