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

[Lofton Henderson <lofton@rockynet.com>]

Since *zero* TC members other than Dieter and me -- not users, not vendors, 
no one -- have expressed any opinion, or even replied to Dave's Poll ... 
then I have to agree with one of Dieter's assertions:  no one cares how 2.0 
behaves and how it relates to 1.0.

I don't disagree with Dieter on the goodness/badness of the original 1.0 
solution.  I do disagree about whether it is a good idea to impose upon 
users, that their legacy content views differently simply by upgrading the 
viewer to 2.0.

More embedded...

At 11:40 PM 2/18/2006 +0100, Dieter  Weidenbrück wrote:
>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.

One small nit, to avoid confusion:  the ApsAttr (above) is 'viewcontext'; 
the fragment object behavior that activates it is 'view_context'.  (Now, 
that's easy to remember ... NOT!)


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

In 2.0 environments (new), the user can completely control all aspects of 
object behavior.  So new 2.0 content can be made to match old (1.0) rules, 
or whatever.


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

This is good feedback.  Judging by the TC response on this topic, Itedo's 
must have all of the WebCGM (or ATA, S1000D, ...) users.  Or the only ones 
that care about what they get from their vendor.


>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

And as explained, Lofton only became concerned when he saw in the test 
suite, what are the implications of that seemly innocent little change (25% 
of tests would behave differently).

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

I wouldn't *require* a switch.  I would suggest that vendors (at least some 
of 'em) consider it as a wise business choice.  Because no matter how we 
resolve it (the standard behavior), I suspect someone's users will be unhappy.

Since no other TC members care about the issue, I will not fight for the 
change I suggested.  (Unhappy users in the future can beat up on their 
vendors to add the secret "treat-1.0-content-per-1.0-rule" switch).

Regards,
-Lofton.


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