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" <>
To: "Dieter" <>; <>
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:
>
*******************
>
