OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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?


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
>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
>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:
>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.
>-----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
>but I think it is implied by and consistent with several bits taken
>together.  These references are relevant:
>References from spec.
>-- 'visibility' ApsAttr definition:
>-- 'src' parameter:
>-- Object behaviors,
>The 'visibility' definition [1] applies, whether the visibility has been
>set by an ApsAttr in the metafile, or by the setAppStructureAttr()
>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
>'interactivity' attribute is changed to off, but simply that the user
>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,
>a navigation with highlighting would not highlight, nor (presumably)
>the highlight() method have an effect.  (This is not directly relevant
>your scenario, because you said 'zoom', and [3] says that this
>parameter has no highlighting side effect.)
>Nothing that I find in [2] or [3] contradicts this opinion -- navigate
>invisible object.
>So it really comes down to what one thinks is sensible.  Whereas you
>pick or interact with an invisible object, on the other hand the object
>there.  So someone knows it is there, and wants to go to it.  The fact
>it is invisible could be semi-permanent (if via ApsAttr in the
>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
>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'").
>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
> >>
> >>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
> >
> >

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]