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

[Lofton Henderson <lofton@rockynet.com>]

Benoit, All --

I pondered similar questions, about the no-highlighting restriction for 
invisible objects.

I'm guessing, but cannot point to firm evidence, that we discussed it 
during 2.0 development and that it was intentional -- the logic might have 
been that visibility setting (on/off) should have higher priority than a 
highlighting request.  (And a highlighting request should not have the side 
effect of toggling explicit 'off' visibility back to 'on'.)

It can be argued either way, and (IMO) neither choice is obviously right or 
wrong.

If the TC decides that it now wants to make an exception for highlighting 
keywords in Object Behaviors, so that abc.cgm#id(myId,addHighlight) will 
highlight an invisible object, then peripheral questions to answer would 
be:  should this result in a clarifying erratum for 2.0?  Or is it new 
functionality (changed behavior) for 2.1?

Also, what about the highlight() DOM method?  Suppose...

myObj.setAppStructureAttr('visibility', 'off')
highlight(myObj-as-a-nodelist, 'add')

Does the highlight have priority and override the invisibility request, 
i.e., does highlighting have the side effect of toggling visibility 'on' 
for invisible objects?  Or is the highlight request saved until visibility 
is explicitly turned on?  Or...?

-Lofton.

At 03:39 PM 7/7/2009 -0400, Bezaire, Benoit wrote:
>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
>
>
>---------------------------------------------------------------------
>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