Re: WebCGM preview

[Dieter@isodraw.de (Dieter Weidenbrueck)]

Lofton,

 

I hate to come up with major changes at this point, it just shows that I should have thought about it earlier. So here is another table proposing the minimal changes that make sense.

We definitely need to apply changes to make 3.2.1.1. and 3.1.2.4. consistent, one way or the other.

 

As far as IsoView is concerned I can still change the implementation to whatever comes out of this discussion. I can go either way without problem. However, I see Harry's good comments, and I know that some of the current definitions will at least disappoint users.

 

So here goes:

 

 Table of current Object Behaviors, compiled from 3.1.2.4. and 3.2.1.1.

 

Attributes:		Fragments:
Object has	and	#myObj (default behavior)	#id(myObj,view_context)	#id(myObj,highlight)	#id(myObj,highlight_all)
view_context	region	zoom to view_context rectangle (3.2.1.1.)	zoom to view_context AND highlight (3.1.2.4.)	full-picture view and highlight first object (3.1.2.4.)	full-picture view and highlight all objects (3.1.2.4.)
view_context	no region	zoom to view_context rectangle (3.2.1.1.)	zoom to view_context AND highlight (3.1.2.4.)	full-picture view and highlight first object (3.1.2.4.)	full-picture view and highlight all objects (3.1.2.4.)
no view_context	region	"move" object into view (3.2.1.1.)	same as #id(myObj,highlight) (3.1.2.4.)	full-picture view and highlight first object (3.1.2.4.)	full-picture view and highlight all objects (3.1.2.4.)
no view_context	no region	"move" object into view and highlight in some way (3.2.1.1.) full-picture view	same as #id(myObj,highlight) (3.1.2.4.)	full-picture view and highlight first object (3.1.2.4.)	full-picture view and highlight all objects (3.1.2.4.)

 3.2.1.1. defines the default behavior only, it doesn’t apply as soon as the fragment contains a specific object behavior.

 Proposed changes (changes in red, comment numbers in blue):

 

Attributes:		Fragments:
Object has	and	#myObj (default behavior)	#id(myObj,view_context)	#id(myObj,highlight)	#id(myObj,highlight_all)
view_context	region	zoom to view_context rectangle and highlight (3.2.1.1.) (1)	zoom to view_context AND highlight (3.1.2.4.)	full-picture view and highlight first object (3.1.2.4.)	full-picture view and highlight all objects (3.1.2.4.)
view_context	no region	zoom to view_context rectangle and highlight (3.2.1.1.) (1)	zoom to view_context AND highlight (3.1.2.4.)	full-picture view and highlight first object (3.1.2.4.)	full-picture view and highlight all objects (3.1.2.4.)
no view_context	region	zoom to region and highlight (3.2.1.1.) (2)	zoom to region and highlight (3.1.2.4.) (4)	full-picture view and highlight first object (3.1.2.4.)	full-picture view and highlight all objects (3.1.2.4.)
no view_context	no region	zoom to geometry and and highlight (3.2.1.1.) (3)	zoom to geometry and and highlight (3.1.2.4.) (4)	full-picture view and highlight first object (3.1.2.4.)	full-picture view and highlight all objects (3.1.2.4.)

 

(1)             Alternative: delete text in 3.2.1.1. and replace by “Default behavior is view_context as described in 3.1.2.4.” This would delete the redundant stuff.

(2)             Replace the ambiguous “move into view” with a behavior that is as close to view_context behavior as possible. This is backward compatible, because the new behavior of course also “moves the object into view”.

(3)             I suggest to remove the “full-picture” statement for  this case. I can’t see a reason why the lack of a region and a view_context attribute should change the typical navigation behavior to a pure highlight behavior.
NOTE:
If we make this a full-picture case this requires all users to add either a region or a view_context to all objects they want to navigate to. They would never be able to navigate to a simple object like a GREXCHANGE 2.4 grobject that has been saved as a WebCGM.

(4)             These two cases need to be changed to match the default behavior described in 3.2.1.1.
For those of you who don’t like this change they would have to change 3.2.1.1. instead. At the end of the day these two paras are inconsistent and need to be aligned. So we can as well do it right now.

 What do you think?

Dieter

 

----- Original Message -----

From: "Lofton Henderson" <lofton@rockynet.com>

To: "Dieter" <dieter@itedo.com>; <cgmopen-members@lists.oasis-open.org>

Sent: Tuesday, May 29, 2001 8:44 PM

Subject: Re: WebCGM preview

> Dieter,
> 
> Thanks for 
the substantial thought and effort you put into this.  However, 
> I 
should note that your table #1, comparison of specifications in 3.1.2.4 
> 
and 3.2.1.1, is taken from the original 1999 text.  Please have a look at 
> the current text of 2nd release, which I attached to previous 
mail.  The 
> case of default-obj-behavior, no-viewcontext, no-region 
(1st column, last 
> row) actually says this now in the 2nd Release 
text:
> 
> "The resulting view is a full-picture view, not a zoomed 
view."
> 
> This was a previous (year 2000) decision.   
Here are my thoughts on your 
> suggestions:
> 
> 1.  
While I appreciate the appeal of making all of this stuff more 
> 
consistent, I am very much against revisiting resolved issues unless there 
> is a compelling new reason or argument, particularly at this very late 
> (past due!) stage of the 2nd Release (of WebCGM **1.0**).   
Your suggested 
> "zoom to" behavior in fact reverses last year's 
decision.
> 
> 2.  My suggestion was to clarify the case of 
default-obj-behavior, 
> no-viewcontext, region (1st column, 3rd row) 
consistently with that 
> decision -- i.e., the cases only differ in that 
you highlight the 
> primitives if a region is not present, or the region 
if present.
> 
> 3.  The suggestions of column 2, rows 3 and 4, 
actually reverse the 
> specification of the 1999 spec (1st 
release):  "If no ViewContext attribute 
> exists in the object, the 
highlight behavior shall be implemented."  For 
> pretty much the 
same reasons as #1, I don't want to see this done.
> 
> If we had 
had such a nice analysis back in 1998, when we were producing the 
> 
WebCGM REC text, I have no doubt that it would have become the normative 
> specification.  I think the functional specifications are fine, 
and the 
> presentation (table) is excellent.
> 
> My 
objections are "procedural" -- making functional changes (no matter how 
> 
appealing) unless a serious defect exists, and revisiting/revising issues 
> (the "no-zoom" clarification) at a very late stage, without compelling 
reasons.
> 
> -Lofton.
> 
> *******************
> 
Lofton Henderson
> 1919 Fourteenth St., #604
> Boulder, 
CO   80302
> 
> Phone:  303-449-8728
> 
Email:  lofton@rockynet.com
> 
*******************
>