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

["Weidenbrueck, Dieter" <dweidenbrueck@ptc.com>]

Lofton, all,

the main purpose of making an object invisible is that it is not
needed/not desired in the current display state of the illustration. For
me this means, it doesn't "exist" for the viewing user. 

If he clicks there, the click will end up on another visible object or
the background.
If he navigates to the object, the result will be confusing, because the
user will see nothing or some other object that he will confuse with the
invisible object.
If he highlights an invisible object, and the highlighting shows, it
will be confusing as well. Something that "isn't there" all of sudden is
highlighted, and then either disappears or stays visible. If
highlighting would switch visibility back to on, this would break a lot
of applications with a simple misguided link.

As said before, we can build use cases for all pro and con cases,
however, we should think about the mainstream use cases first:
- visibility has higher priority than highlighting
- visibility has higher priority than click behavior

>"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."

What I read here is "a non-visible object behaves like a non-interactive
object". We should find a proper definition for the term
"non-interactive object", otherwise it is ambiguous:

- a grobject can be target of a fragment/DOM navigation and hence of
highlighting behavior
- an interactive grobject can be clicked upon and produce events

I think we are clear about the second case: the object cannot be clicked
upon and produce events or process linkURIs.
The first part is ambiguous, we exclude highlighting as part of the
definition of "non-interactive", however, in my opinion this would as
well eliminate navigation to this object.

In general, this is something to put on a list of needed clarifications.
I don't want to push this for 2.1.

Regards,
Dieter


-----Original Message-----
From: Lofton Henderson [mailto:lofton@rockynet.com] 
Sent: Mittwoch, 8. Juli 2009 02:11
To: Bezaire, Benoit; CGM Open WebCGM TC
Subject: RE: [cgmo-webcgm] Navigation to an invisible object

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


---------------------------------------------------------------------
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