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

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

Lofton,

I can live with the spec as is, especially looking at the timeframes.
However, I believe that we should clarify the wording in those two
sections.

Highlighting may occur in three different ways:
- as an object behavior upon execution of a fragment
- as the result of the DOM highlight() call
- as the response to a mouse click to indicate interactivity

The spec uses the word highlight in all three cases without
distinguishing between them.
For example, in 3.2.2.10, the spec says:

"This has the effect of disabling event handlers, cursor changes,
highlighting, screentip and hyperlinking for the given node and its
descendant. An object that is the target of a link always responds to
highlighting, regardless of its 'interactivity' attribute value."

The first "highlighting" means the response to a mouse click, and it
correctly is disabled. The second sentence uses "highlighting" to talk
about object behaviors, and here it is (correctly) enabled.
We should not use the same word to describe different concepts without
making sure that people don't get confused (like I was).

I suggest to put it on a maintenance list for the post-2.1 world.

Dieter

-----Original Message-----
From: Lofton Henderson [mailto:lofton@rockynet.com] 
Sent: Mittwoch, 8. Juli 2009 17:13
To: cgmo-webcgm@lists.oasis-open.org
Subject: Re: Fwd: RE: [cgmo-webcgm] Navigation to an invisible object

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


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