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

[Lofton Henderson <lofton@rockynet.com>]

 From Dieter...

>Date: Wed, 8 Jul 2009 10:52:30 -0400
>From: "Weidenbrueck, Dieter" <dweidenbrueck@ptc.com>
>To: "Lofton Henderson" <lofton@rockynet.com>
>
>Lofton,
>
>[...] I can't join right now.
>
>Please consider my specific comment:
>The word "highlighted" in the current wording does NOT refer to object
>behavior, it means the highlighting as a response to mouse-clicks. So
>the current spec does NOT define what should happen in the case of an
>object navigation at all.
>
>Dieter
>
>-----Original Message-----
>From: Lofton Henderson [mailto:lofton@rockynet.com]
>Sent: Mittwoch, 8. Juli 2009 16:49
>To: Weidenbrueck, Dieter
>Subject: RE: [cgmo-webcgm] Navigation to an invisible object
>
>Dieter -- [...] we're discussing this in TC telecon now.
>
>The group is pretty unanimous -- for invisible objects navigate and
>honor
>nav keywords, ignore highlight keywords.
>
>-Lofton.
>
>At 10:34 AM 7/8/2009 -0400, Weidenbrueck, Dieter wrote:
> >Lofton,
> >
> >ok, let me try:
> >
> > > >"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."
> >
> >"A non-visible object is not displayed."
> >No objections.
> >"A non-visible object behaves like a non-interactive object (i.e., it
> >cannot be clicked or highlighted."
> >The use of the word "highlighted" is ambiguous. Discussions so far have
> >assumed that the meaning is "highlighting as defined in object
> >behaviors". After reading 3.2.2.10, I am convinced that we are talking
> >about highlighting as a feedback to a mouse-click on an interactive
> >object only. Object behaviors are not mentioned at all IMO.
> >
> >
> >Suggestion for a change:
> >
> >"Viewer behavior. A non-visible object is not displayed. A
> >non-visible object behaves like a non-interactive object (i.e., it
> >doesn't respond to mouse events as defined in 3.2.2.10). This does not
> >imply that the 'interactivity' attribute is changed to off, but simply
> >that the user agent must not respond to mouse events. If the
>non-visible
> >object is the target of a navigation, the navigation including all
> >object behaviors (navigation and highlighting) is ignored."
> >
> >This would clarify the situation.
> >
> >One more comment:
> >it might be worth to have a look at 3.2.2.10 as well. It talks about
> >highlighting twice, the first occurrence is the feedback to a mouse
> >click, the second occurrence refers to object behaviors. Perhaps we
> >should clarify this.
> >
> >Thoughts?
> >
> >Regards,
> >Dieter
> >
> >-----Original Message-----
> >From: Lofton Henderson [mailto:lofton@rockynet.com]
> >Sent: Mittwoch, 8. Juli 2009 16:06
> >To: CGM Open WebCGM TC
> >Subject: RE: [cgmo-webcgm] Navigation to an invisible object
> >
> >Dieter, All --
> >
> >I guess I disagree with your final conclusion, "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."
> >
> >If one takes the most direct interpretation of the words of 2.0, then
> >...
> >highlighting requests are not honored for non-visible objects.
> >Navigation
> >to such objects is not proscribed.  Those are the present words.  If it
> >is
> >not what we want, then we need to decide quickly.
> >
> >That said, navigating to non-visible objects is a dubious or risky
> >practice.  (If I were writing a viewer, I would create a log-file entry
> >--
> >a warning or alert.)
> >
> >If we want different interpretation, we need a concrete proposal, and
> >quickly...  2nd LCWD review of 2.1 has closed.
> >
> >Regards,
> >-Lofton.
> >
> >
> >At 02:12 AM 7/8/2009 -0400, Weidenbrueck, Dieter wrote:
> > >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
> >
> >
> >---------------------------------------------------------------------
> >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