I prefer clearHighlight; it is needed.
Regards
Ulrich
----- Original Message -----
Sent: Tuesday, July 05, 2005 6:22
PM
Subject: RE: [cgmo-webcgm] ISSUE: is
noHighlight functionality needed?
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
|