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

[Lofton Henderson <lofton@rockynet.com>]

Dieter,

After your last message, we polled implementors:

** all 3 implementors who are present do in fact navigate to invisible 
objects (via fragment nav keywords);

So they apparently interpreted 2.0 as NOT restricting navigation to 
invisible objects.  To make that interpretation now would force changing 
three implementations.

** all present agreed that visibility should have priority and highlighting 
should be suppressed (whether via object behavior or highlight() method).

We might have written this better during 2.0 development 3 years ago, but 
the text has been interpreted by most implementors as:  nav-to-invisible 
okay, and nav keywords okay; but DO NOT highlight, regardless of the source 
of the highlight request.

What next?

-- We can discuss the resolution some more, but there is unanimity on the 
TC telecon now.
-- We can leave the spec as is.  Or we can add minimal clarification of the 
above, which is how the 3 present implementations do it.

Further thoughts?

-Lofton.

At 09:01 AM 7/8/2009 -0600, Lofton Henderson wrote:
> 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
>
>
>---------------------------------------------------------------------
>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
>
>