RE: [cgmo-webcgm] Viewer behavior with WebCGM 1.0 files

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

Dave, 

IMO, it was a bad choice to define the fallback solution for
viewcontext behavior on objects without a viewcontext the way
WebCGM 1.0 did.

If somebody links to an object from HTML using

...#myObj
or
...#id(myObj,view_context) 

he will see one of the following actions in WebCGM 1.0:

if a view_context attribute is present, the viewer will navigate to the
object
if NO view_context attribute is present, the viewer will go to full view and
highlight the object.

The consequence is, that - according to WebCGM 1.0 - it is impossible to
navigate to an
object unless it has an explicit view_context attribute.
In the market place, the default situation is to have CGMs without
view_context attributes,
so a lot of people rely on this setting. And a lot of people have no chance
to navigate to
objects unless they add view_context attributes all over the places.

Now the same situation, a WebCGM 2.0 viewer is used:
The URL pointing to the CGM from HTML will be the same:
...#id(myObj, view_context)

The integrator will not change the href depending on which version of WebCGM
he will be viewing. He doesn't even know at runtime without big effort.

So we decided to map view_context to zoom+newHighlight, the default behavior
in WebCGM 2.0.
I understand that there is a change from WebCGM 1.0 to WebCGM 2.0, however,
if we DON'T change it,
we will cause a lot of confusion in mixed 1.0 and 2.0 environments. Plus it
will never be possible
to navigate to an object using 1.0 behavior without explicit view_context.

Our users WANTED to navigate to objects, they did not want a fundamentally
different behavior (highlight + full view) if they would navigate to an
object without attribute. So we made this the standard behavior of our
software.

If the group - after having discussed this a long time ago, and after no
objections to this change from all people who are expected to revisit it
now, and after the lack of concern showed at the last telecon from all
except Lofton - wants to change this, we will accept this. However, we will
not change the behavior of IsoView to follow this decision, because our
users explicitely asked us to have it this way.

If you decide to require a switch, it only means more work for the vendors,
I don't see any practical benefit coming out of this.

Hence: Leave it as it is now.

Regards,
Dieter

> -----Original Message-----
> From: Cruikshank, David W [mailto:david.w.cruikshank@boeing.com] 
> Sent: Saturday, February 18, 2006 11:22 PM
> To: CGM Open WebCGM TC
> Subject: [cgmo-webcgm] Viewer behavior with WebCGM 1.0 files
> 
> This question started out as a dialog
> (http://www.oasis-open.org/apps/org/workgroup/cgmo-webcgm/emai
> l/archives
> /200602/msg00010.html). 
> 
> Here is a statement of the issue.  Please follow up this 
> message with your opinion.
> 
> Obviously, when dealing with WebCGM 2.0 files, WebCGM 2.0 
> viewers will implement the correct default behavior according 
> to the 2.0 spec.  When dealing the WebCGM 1.0 files, WebCGM 
> 1.0 viewers will implement the correct default behavior 
> according to the 1.0 spec.
> 
> WebCGM 2.0 defined a mapping from WebCGM 1.0 default behavior 
> when dealing with WebCGM 1.0 files.
> 
> It was pointed out that when users upgrade their viewers to 
> WebCGM 2.0 without upgrading to WebCGM 2.0 files, they will 
> see a change in default behavior.  Is this the desired result?
> 
> Should control of the default behavior in this case be 
> offered to the users by the vendors?  Should this be a 
> business decision by the vendors based on user requirements?
> 
> In any case, we may have to revisit this issue during the W3C 
> processing.
> 
> Thoughts?
> 
> Thx...Dave Cruikshank
> 
> Technical Fellow - Graphics/Digital Data Interchange Boeing 
> Commercial Airplane 206.544.3560, fax 206.662.3734  <-- NEW 
> NUMBERS david.w.cruikshank@boeing.com
> 
>