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

[Lofton Henderson <lofton@rockynet.com>]

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

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)

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

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.

-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