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

[Lofton Henderson <lofton@rockynet.com>]

All --

Summarizing recent discussions...

First, thanks to Dieter for your careful reading and thinking about the 
problem.

Second, we all need to keep remembering that we're talking about odd, 
fringe cases that are *not* a core capabilities or core use cases -- 
manipulation/navigation of invisible objects?  The most important outcome 
should be clarified descriptions that maximally align with the 
most-implemented (interpretations).

Finally, on to "what next?"...

Below Dieter said, "I suggest to put it on a maintenance list for the 
post-2.1 world."  That indeed is an option, to treat it as an erratum and 
drop it for now.  That could work *if* it is unarguably "non-substantive 
editorial clarification."  (Which is easy if all implementations agree, and 
if we are unanimous.)  The other option would be simple, minimal 
clarification now, before we publish 2.1.  (And consider an erratum for 2.0 
... gotta' check about that.)

I do agree with your below analysis that 2.0 text lumps together several 
senses of highlighting, and it muddies the water in the 'visibility' 
definition by using "non-interactive" to compare *some* of the properties.

For convenience, here are the quotes from 2.0...

[[[
>3.2.2.9 Visibility:
>-----
>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.
>
>3.2.2.10 Interactivity:
>-----
>When the 'interactivity' of an object is set to off, events for this 
>object are disabled. 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 consensus of Wednesday's TC telecon -- i.e., the best and most direct 
interpretation of the potentially ambiguous 2.0 wording -- was this:

1.) navigation to invisible objects:  YES, and in particular the nav 
keywords of the Object Behaviors are executed as specified.  (At least 3 
implementations, and unanimous opinion of those present.)

2.) highlighting invisible objects (3 sub-parts; unanimous amongst all 
those present):
     -- highlighting keywords in Object Behaviors are ignored.  I.e., 
'visibility' has priority, i.e., "a non-visible object is not displayed".
     -- highlight() method:  ignored.  I.e., 'visibility' has priority, 
i.e., "a non-visible object is not displayed".
     -- mouse-over, mouse clicks on object, etc, ... highlighting behavior 
is suppressed.

It would be pretty easy to editorially disambiguate the wording of 3.2.2.9 
& 3.2.2.10 to reflect those (implemented) meanings, #1 and #2.  I will put 
it to the WG, including sample of minimal clarification, to decide how to 
proceed.   (Having now established a high amount of agreement, if not 
unanimity, in the TC.)

Regards,
-Lofton.

At 11:22 AM 7/8/2009 -0400, Weidenbrueck, Dieter wrote:
>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
>
>
>---------------------------------------------------------------------
>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