RE: [cgmo-webcgm] Navigation to an invisible object

["Bezaire, Benoit" <bbezaire@ptc.com>]

Hi All,

Reading:

"Viewer behavior. A non-visible object is not displayed. A non-visible
object behaves like a non-interactive object (i.e., it cannot be clicked
or highlighted). This does not imply that the 'interactivity' attribute
is changed to off, but simply that the user agent must not respond to
mouse events."

I wonder if "or highlighted" should be there? The intent of that
sentence was to say that non-visible objects cannot be clicked on.

I don't recall a discussion about allowing (or not) the highlighting of
non-visible objects.

I think the spec is clear enough about abc.cgm#id(myId,zoom)
but not so clear about abc.cgm#id(myId,addHighlight)

Benoit.

-----Original Message-----
From: Lofton Henderson [mailto:lofton@rockynet.com] 
Sent: Monday, July 06, 2009 5:10 PM
To: CGM Open WebCGM TC
Subject: [cgmo-webcgm] Navigation to an invisible object

Hi All,

Dieter & I had a discussion about a WebCGM 2.0 question of
interpretation, below attached.  We thought it might interest others,
and I would be interested to hear others' opinions.

Again, this is about WebCGM 2.0.  While we conclude that no normative
corrections are in order, it is possible that an informative, clarifying
note could be added.  IMO, that is not necessary.  But I wouldn't
object, if there is consensus that further clarification should be
added.  See and read below, for the complete discussion, including
references in the WebCGM text, and including Dieter's suggestions for
some detailed clarifications.

SYNOPSIS.  WebCGM is clear that one cannot interact with invisible
objects (see details below).  It is less clear whether one could
navigate to an invisible object, using for example the object behaviors
in a URI such as abc.cgm#id(myId,zoom).  The object could be invisible
via an ApsAttr in the metafile itself, or could be transiently invisible
via
setAppStructureAttr() DOM method, or could be invisible because it has
no content (a case that Dieter mentions).

CONCLUSION.  Because it is not proscribed, and because there are use
cases both for it, we conclude that it is valid.  (To be sure, there are
counter-use-cases that indicate it could be problematic, and Dieter
illustrates a couple below.)  Also, nothing in the spec prevents viewers
from having value-added features such as the ability to warn about the
occurrence of potentially problematic situations.

Thoughts or opinions?

Regards,
-Lofton.

At 03:23 AM 7/3/2009 -0400, Weidenbrueck, Dieter wrote:
>Hi Lofton,
>
>I agree with your opinion, this was my first conclusion as well.
>
>Looking from a user's point of view, I wonder whether this makes sense.
>Of course, one could come up with use cases for anything and 
>everything, however, the most common use case should be that something 
>that has been made invisible doesn't play a role in the current state 
>of the displayed graphics.
>Imagine you have several instances of an object in different states, 
>e.g. a switch in different positions. Navigating to one of the 
>invisible instances would take you to an area where other objects may 
>be visible, so this may be misleading, especially if no highlighting is
happening.
>
>And then we have mixed situations. Imagine 3 objects on a schematic
>diagram:
>ID: R1 Name: Resistor
>ID: R2 Name: Resistor
>ID: R3 Name: Resistor
>
>So they share the same name. Now R2 is made invisible, later on a 
>navigation happens:
>#name(Resistor,move)
>
>2 are visible, the third one not. What do you navigate to?
>
>Bottom line:
>Looks like the standard does make a statement about an invisible object

>no longer being interactive, however, it probably should say something 
>about an invisible object being the target of a navigation in general.
>And that part should distinguish between an object that has been made 
>invisible temporarily vs. an object that is not visible in general,
e.g.
>an empty APS with a region on top of a raster.
>
>[...]
>
>Cheers, and thanks for your comments.
>Dieter
>
>
>-----Original Message-----
>From: Lofton Henderson [mailto:lofton@rockynet.com]
>Sent: Freitag, 3. Juli 2009 00:51
>To: Weidenbrueck, Dieter
>Subject: Re: Navigation question
>
>Hi Dieter,
>
>Okay, I'm going to stick with my initial opinion:  navigate to 
>invisible
>
>object and leave it invisible.
>
>There is no single place in the spec that directly addresses your 
>scenario, but I think it is implied by and consistent with several bits

>taken together.  These references are relevant:
>
>References from spec.
>-- 'visibility' ApsAttr definition:
>[1]
>http://www.w3.org/TR/2009/WD-webcgm21-20090604/WebCGM21-IC.html#webcgm_
>v
>isibility
>
>-- 'src' parameter:
>[2]
>http://www.w3.org/TR/2009/WD-webcgm21-20090604/WebCGM21-DOM.html#webcgm
>m
>etafile-src
>
>-- Object behaviors, 3.1.2.4:
>[3]
>http://www.w3.org/TR/2009/WD-webcgm21-20090604/WebCGM21-IC.html#webcgm_
>3
>_1_2_4
>
>The 'visibility' definition [1] applies, whether the visibility has 
>been
>
>set by an ApsAttr in the metafile, or by the setAppStructureAttr() 
>method of the DOM.  It says:  "Viewer behavior. A non-visible object is

>not displayed. A non-visible object behaves like a non-interactive 
>object (i.e., it cannot be clicked or highlighted). This does not imply

>that the 'interactivity' attribute is changed to off, but simply that 
>the user agent must not respond to mouse events."
>
>That is sensible enough, but not particularly prescriptive.  However, 
>it
>
>does contain a useful bit of information:  invisible objects cannot be 
>highlighted.  I.e., 'visibility' is higher priority than highlighting, 
>and a navigation with highlighting would not highlight, nor 
>(presumably) would the highlight() method have an effect.  (This is not

>directly relevant to your scenario, because you said 'zoom', and [3] 
>says that this navigation parameter has no highlighting side effect.)
>
>Nothing that I find in [2] or [3] contradicts this opinion -- navigate 
>to invisible object.
>
>So it really comes down to what one thinks is sensible.  Whereas you 
>cannot pick or interact with an invisible object, on the other hand the

>object is there.  So someone knows it is there, and wants to go to it.

>The fact that it is invisible could be semi-permanent (if via ApsAttr 
>in the metafile), or transient (if via setAppStructureAttr).  I see no 
>reason why the navigation should be denied.  (And per above, I believe 
>that the invisibility should not be changed.)
>
>You asked, should viewer "issue warning".  The spec neither requires it

>nor prohibits it.  I think it would be a nice value-added feature for a

>viewer.  Maybe have a little icon that is highlighted when something 
>unusual happens, and takes you to informative message(s) like, "viewer 
>navigated to invisible object 'myId'").
>
>Thoughts?
>
>Cheers,
>-Lofton.
>
>At 10:21 AM 7/1/2009 -0600, Lofton Henderson wrote:
> >Dieter,
> >
> >Good question.  I'm definitely going to have to look and think more.
> >
> >But off the top of my head, what I think would be sensible would
> >be:  navigate to the invisible object, and leave it invisible.  
> >(WebCGM
>
> >2.0 says that the keyword 'zoom' alone has no effect on highlighting 
> >or
>
> >visibility.)
> >
> >As I said, I'll research a little more and see what the words in the 
> >standard actually say.
> >
> >Cheers,
> >-Lofton.
> >
> >At 09:48 AM 7/1/2009 -0400, Weidenbrueck, Dieter wrote:
> >>Lofton,
> >>
> >>what's your opinion about the following question related to
>navigation:
> >>
> >>Let's assume a CGM that contains a grobject with the ID "myID"
> >>
> >>while the file is being displayed in a viewer, we want to navigate 
> >>to this object using
> >>
> >>...abc.cgm#id(myID,zoom)
> >>
> >>Now comes the problem:
> >>What is the recommended/standardized behavior, if the object has 
> >>been made invisible by a prior DOM call?
> >>
> >>1. navigate to invisible object
> >>2. no navigation at all
> >>3. issue warning
> >>4. ???
> >>
> >>Any idea?
> >>
> >>Cheers,
> >>Dieter
> >
> >


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php