Lofton,
I looked at the two paras and compared them. Here
is the result:
Table of 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.)
shrink to fit and highlight first object
(3.1.2.4.)
shrink to fit 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.)
shrink to fit and highlight first object
(3.1.2.4.)
shrink to fit 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.)
shrink to fit and highlight first object
(3.1.2.4.)
shrink to fit 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.)
same as #id(myObj,highlight)
(3.1.2.4.)
shrink to fit and highlight first object
(3.1.2.4.)
shrink to fit 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.
Object behaviors in
general
I suggest we
understand the behaviors as follows:
-
if view_context is used the intention is to
NAVIGATE TO the object. In my humble opinion this means to move the object(s)
into view and zoom into the illustration to make them the dominant part of the
viewer rectangle. If the object has a view_context attribute this is what
happens, however, if there is no view_context attribute I suggest we keep the
behavior as close as possible to the one using a
view_context.
-
If highlight (highlight_all) is used the
intention is to SHOW the object(s) and visually discriminate it (them) from
others.
The
following table shows in red the suggested changes.
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 flash (3.1.2.4.)
shrink to fit and highlight first object
(3.1.2.4.)
shrink to fit 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 flash (3.1.2.4.)
shrink to fit and highlight first object
(3.1.2.4.)
shrink to fit and highlight all objects
(3.1.2.4.)
no view_context
region
Zoom to object region such that the
region fills a significant part of the viewer rectangle
(3.2.1.1.)
Zoom to object region such that the
region fills a significant part of the viewer rectangle and flash region
(3.1.2.4.)
shrink to fit and highlight first object
(3.1.2.4.)
shrink to fit and highlight all objects
(3.1.2.4.)
no view_context
no region
Zoom to object primitives such that
the enclosing rectangle fills a significant part of the viewer rectangle
(3.2.1.1.)
Zoom to object primitives such that
the enclosing rectangle fills a significant part of the viewer rectangle
and flash region (3.1.2.4.).
shrink to fit and highlight first object
(3.1.2.4.)
shrink to fit and highlight all objects
(3.1.2.4.)
This would
accomplish the following:
-
remove differences between default behavior and
view_context behavior. 3.2.1.1. could actually point to 3.1.2.4 from then
on
-
clarify the “move into view” expression in
3.2.1.1
The term "flash" suggests some kind of highlighting
different to the one used in the "highlight" cases.
Let me know what you think,
Dieter
----- Original Message -----
From: "Lofton
Henderson" <>
To: "Dieter" <>; <>
Sent: Tuesday, May 29, 2001 6:07 PM
Subject: Re: WebCGM preview
> At 05:04 PM 5/29/01 +0200, Dieter
Weidenbrueck wrote:
> >[...]
> >Comments:
>
>
>1. The wording is a bit confusing:
>
> Tell me about
it!!!
>
> >For an object that has a view_context
attribute
> >- 3.1.2.3 suggests both navigation AND highlight plus a
default behavior
> >(highlight)
> >- 3.2.1.1 suggests
navigation only
> >This should be made consistent.
>
> I
agree. We have talked to Chris and will delay Second Release for another
> week or so, while we straighten it out.
>
> >The
combined navigation and highlighting of course only works if there is a
>
>body, i.e. if graphical primitives exist.
> >Also the last sentence
of the view_context para should read
> >"The view_context behavior is
the default behavior."
> >The current language is probably misleading
with regard to the highlight
> >statement right before the "This
is...".
>
> Yes, I noticed the same and it bothered me as
well.
>
>
> >It becomes obvious that the viewer behavior
leaves a lot of room for
> >interpretation. The requirement "... moves
the object into view" for example
> >is met in your example, because a
shrink-to-fit representation does of
> >course show the object.
However, this example really doesn't show the
> >difference between
highlight and view_context.
> >IsoView will move the object into view
and zoom into the illustration so
> >that the object becomes the
dominant part in the viewer rectangle.
>
> I want to call attention
to a 2nd Release clarification which is already in
> the draft 2nd
Release text, and which was discussed several times (and
> finalized, I
think, either at the 6/00 Autotrol meeting or the 12/00 DC
>
meeting):
>
> The third bullet, at the end of 3.2.1.1, now
reads:
>
> "If the object contains neither a view context nor a
region attribute, the
> viewer shall move the object into view and
indicate
> visually that the graphical primitives of the grobject are the
target of
> the link. The manner in which the viewer creates the
new
> display is viewer dependent. The resulting view is a full-picture
view, not
> a zoomed view."
>
> Note the new last sentence
to this paragraph, clarifying the ambiguity
> which you noted
above.
>
> (Note. I see no problem with offering different
behaviors as viewer
> options. But the viewer has to be capable of
the specified behavior, and
> it should be the default, in the absence of
user option setting.)
>
>
> >BTW, we recently decided to
use lowercase for all attributes/tag names.
> >Throughout the spec
almost all possible variants of "view_context",
> >"linkuri" etc are
used. Will we adjust the spelling in the spec to lowercase
> >as
well?
>
> Yes, I will work with Dave to make it as consistent as
possible. Note that
> we never had any problem with the
"view_context", which is a *value* of the
> object behavior parameter (of
the fragment). But it does get confusing
> because we refer
to:
>
> 1. "ViewContext" -- as a generic term for the view context
concept.
> 2. "ViewContext" -- as the value of the APS attribute 'type'
parameter,
> indicating a view context APS attribute.
> 3.
'viewcontext' -- as the value of the APS attribute 'type' parameter,
>
indicating a view context APS attribute.
> 4. "view_context" -- as a
possible value for the object behavior bit of the
> fragment.
>
> Anyway, we'll sort it out.
>
> -Lofton.
>
