OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [cgmo-webcgm] ISSUE: does the 'highlight' object behavior revert to full-picture view?


Lofton,

see inline

> -----Original Message-----
> From: Lofton Henderson [mailto:lofton@rockynet.com]
> Sent: Monday, June 13, 2005 2:42 PM
> To: dieter@itedo.com; cgmo-webcgm@lists.oasis-open.org
> Subject: RE: [cgmo-webcgm] ISSUE: does the 'highlight' object behavior
> revert to full-picture view?
>
>
> At 08:32 AM 6/10/2005 +0200, =?us-ascii?Q?Dieter__Weidenbruck?= wrote:
> >[...]
> > > ii.) The 'highlight' keyword is useless.  When a program or an
> > > XCF issues a
> > > 'highlight' behavior, it has no way of knowing what is the present
> > > view.  Another DOM or WebCGM or XCF transaction may have
> changed it.  Or
> > > the user may have panned/zoomed the picture with viewer
> controls.  It is
> > > unknowable, in general, whether the target to be highlighted is
> > > visible.  Therefore, no one would risk using 'highlight' (or
> > > 'highlight_all').  Only 'move_highlight' or 'zoom_highlight' have any
> > > usefulness.
> >It is not useless in my eyes, it becomes much more powerful now. So far,
> >users rarely used this keyword because of the unwanted
> navigation effects.
> >Combinations with navigation are well defined now, so highlight
> is reserved
> >for the cases where the implementor well knows what he is doing.
>
> Did you indeed mean "implementor"?  To me it seems like an issue for
> users/content creators.  What content creator would use such a
> non-navigating "full" keyword in a hyperlink fragment, without any way to
> know how the user may have moved the view with the viewer
> controls?  If the
> content creators and other users cannot trust the result, who
> would use "full"?
Sorry, I meant the implementor of an IETM, hence a content creator.
There are many use cases for this, e.g. in scenarios where the viewer is set
to "fixed" in the OBJECT tag, but also in others.
I think a strict separation of the behaviors highlight, move, zoom, full is
very
useful to clarify the actual behavior.

Have a look at the following sequence:
abc.cgm#id(myView,zoom)
abc.cgm#name(myFirstObj,highlight)
abc.cgm#name(mySecondObj,highlight)
abc.cgm#id(myThirdObj,highlight)

(assumed that the three objects are inside the rect established by myView).

Typical thing that you can't do in other ways unless you start playing a lot
with
multiple name attribute on objects.


>
> [Btw, this is ignoring for the moment the "new wrinkle" (issue) I pointed
> out yesterday, that the current picture-behavior wording of the spec does
> not seem to support successive object behaviors being cumulative,
> even with
> intra-CGM links in the same file.]
I will answer that one separately.

>
> -Lofton.
>
>
Cheers,
Dieter



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]