RE: [cgmo-webcgm] ISSUE: is noHighlight functionality needed?

[Lofton Henderson <lofton@rockynet.com>]

Dieter and I agree on details, so let me summarize (for closure
Wednesday) as a...

PROPOSAL:

Add a limited 'noHighlight' object behavior, in order to be able to
return to highlight-free state in a sequence where things have previously
been highlighted:

#id(*, noHighlight)

is the only allowed form.  The special object selector
"*" selects all objects and may only be used with the
noHighlight keyword.  The noHighlight keyword may not be used in
combination with any navTerm keywords.  (If you want navigation, do
it in a separate behavior fragment before or after the clearing of the
highlighting.)  The character repertoire for names (3.1.1.3) will
indicate that "*" is not a valid name for an object or group of
objects

Are people happy with this approach?  If yes, do you prefer
noHighlight or clearHighlight, for the new keyword?

-Lofton.

At 03:42 PM 7/5/2005 +0200, =?us-ascii?Q?Dieter__Weidenbruck?=
wrote:

see inline

-----Original Message-----

From: Lofton Henderson [mailto:lofton@rockynet.com]

Sent: Tuesday, July 05, 2005 3:18 PM

To: dieter@itedo.com; cgmo-webcgm@lists.oasis-open.org

Subject: RE: [cgmo-webcgm] ISSUE: is noHighlight functionality needed?

More comments / preferences in line...

At 08:22 PM 7/4/2005 +0200, =?us-ascii?Q?Dieter__Weidenbruck?= wrote:

Lofton,

 

see my response inline

-----Original Message-----

From: Lofton Henderson [mailto:lofton@rockynet.com]

Sent: Monday, July 04, 2005 8:07 PM

To: dieter@itedo.com; cgmo-webcgm@lists.oasis-open.org

Subject: RE: [cgmo-webcgm] ISSUE: is noHighlight functionality needed?

Questions for clarification inline...

At 10:18 AM 7/2/2005 +0200, =?us-ascii?Q?Dieter__Weidenbruck?= wrote:

Lofton,

see my comments inline.

-----Original Message-----

From: Lofton Henderson [mailto:lofton@rockynet.com]

Sent: Saturday, July 02, 2005 12:04 AM

To: cgmo-webcgm@lists.oasis-open.org

Subject: [cgmo-webcgm] ISSUE: is noHighlight functionality needed?

Source:  editors

ISSUE:  do the object behaviors need a way to turn off existing highlighting?

DISCUSSION:

The spec (6/28 Editors draft, reviewed at last telecon) says:  "The object behaviors are built from a set three "atomic" navigation keywords and a set of two "atomic" highlight keywords, defined below. The navigation keywords have no highlighting side effects and the highlighting keywords have no navigation side effects -- the navigation and highlighting keyword sets are orthogonal."  This is a basic principle of the new object behaviors scheme.

There appears to have been some leftover expectation that 'move' would clear existing highlighting (comments at last telecon).  But the newly articulated orthogonality between navTerm and highlightTerm would say ... if a picture is displayed, and if anything is already highlighted, then 'move' should leave it alone. 

This would leave one functionality missing:  the ability to clear highlighting (with or without a change of view).  E.g., one could not return to a full_noHighlight view once any highlighting behaviors had been invoked.  For reference:

-- newHighlight erases any existing highlight and then applies the new highlighting.

-- addHighlight applies the new highlighting, leaving any existing highlighting alone.

Note that this issue only arises in the context of cumulative behavior, which we have only just recently started to clarify.  I.e., it is easy to specify object behaviors that, upon initial load, have any desired highlight state.  But it is XCF or DOM sequences like the following that become problematic.

#(someName, zoom_newHighlight)

#(someId, zoom_newHighlight)

[same view all highlighting off] or

[full picture no highlighting] or ...

The [...] capabilities of the last two lines are not there.

ALTERNATIVES:

1.) do nothing: which means you can't return to a no-highlight state, once something has been highlighted (i.e., "the functionality is not important enough")

[DW] That is not an option for me, because I don't want to have to reload the file and loose my DOM/XCF work just because I want to remove highlighting.

2.) compromise "orthogonal": move (& other nav. keywords?), when alone, implicitly clear highlighting (leaving no way to navigate within a picture without affecting the highlighting state).

[DW] This has been discussed at some point, I like other options better.

3.) add some noHighlight functionality to the behaviors:  either for whole picture (i.e., all objects. for example via a wildcard object selector), or for individual target object(s), or both.  [3 flavors here].

[DW] I suggest to add the noHighlight keyword as follows:

#id(someID,noHighlight)                remove the highlighting on someID

#name(someName,noHighlight)     remove the highlighting on all objects with someName

#id( ,noHighlight)

#name( , noHightlight)

Q1:  Is the flavor that targets a specific id or name a useful
capability?  (If not, it would be simple to implement only the
wildcard version as a single, special-case behavior.)
[DW] I consider the
"wildcard" behavior the important one. The specific removal of
highlighting using ID or name is certainly useful, however, I can easily
live with the "wildcard" only.

I don't feel strongly, but I'm leaning towards simplicity rather than
completeness.  (If we find that we omitted something useful, we can
add it later.  But it's harder to remove stuff later).
[DW2] Agreed. Let's just do the
wildcard then. 


> Q2:  Is it part of your
> proposal that noHighlight cannot be used together with a nav term, or am
> I reading too much into your choice of examples?  I.e., would these
> examples be valid or invalid?
> #id(someID,zoom+noHighlight)
> #id(,full+noHighlight)
> [DW] hm...interesting question.
> If we are striving for a wildcard solution, combination with 
> navigation doesn't make sense except for
> "full".
> Then of course your first
> sample here could be interpreted as "remove all highlighting, then
> move to someID", However, that would open
> another door for
> combinations and semantics. It would mean, that a keyword would be used
> on other objects than those specified
> by ID or
> name.
> I don't have a strong
> opinion here, two options:
> A: no combination with
> navigation:
>    
> #id(*,noHighlight)
> B: combination with
> highlight:
>    
> #id(someID,navTerm+noHighlight)
>    
> (meaning: remove all
> highlighting, then navigate to someID
> Thoughts?

Here's another thought... you can always do this sequence:

#id(someID,noHighlight)
#id(someID,navTerm)

If the utility of navTerm+noHighlight seems dubious (which it does to me), then we could opt for simplicity. 
[DW2]  Agreed, no combination then.


> Q3:  If valid, then are there any restrictions on how it combines, e.g., when using the wildcard form?  E.g., 
> #id(,zoom+noHighlight)
> seems nonsensical (while full+noHighlight seems useful).
> [DW] see above 
>
> Concerning using omitted parameter versus a wildcard like "*" (below), I prefer the wildcard.  But ... that means going and editing the character repertoire section 3.1.1.3, #3, 2nd bullet.
> [DW] That's the point. However, we simply need to exclude '*' as a complete name. The likelihood that anybody has objects out there with the name '*' is quite low IMO.
>  
> Additional question:
> I think we only need one variant of these two here:
> #id(*,noHighlight)
> #name(*,noHighlight)
> Do people want both or just one?

I think just one suffices (the 'id' flavor -- it hits all APSs, whereas the 'name' flavor, it seems to me, would only hit those with a 'name' ApsAttr).
[DW2]  Agreed. id flavorsuffices.

[DW2]  Dieter
-Lofton.

Dieter

-Lofton.

The two last ones would remove any existing highlighting on the entire illustration.

Alternatively:

#id(*,noHighlight)

#name(*,noHighlight)

Using a wildcard like '*' requires escaping of the wildcard character if used as a name,

not a big issue, probably we could prohibit '*' as a valid name. The empty string

does not have this problem.

RECOMMENDATION:  none yet.  TC should think and discuss.

[DW] Yes.

-Lofton.

[DW] Regards,

Dieter