Re[4]: [cgmo-webcgm] Highlight test

[Benoit Bezaire <benoit@itedo.com>]

Hi Lofton,

I've expressed my opinion, I would certainly like to hear Dieter's as
well. I just don't see why a user would do what was done in the test.
I could be wrong, but I doubt that's going to happen very often.

Also, the fact that id(*,clearHighlight) is the only way to remove a
highlight (i.e., remove all highlights) using the EBNF complements my
argument... Meaning, if we've only expected the need for a clear all
highlights in the EBNF, why would we need a highlight that behaves
like a Style Property in the DOM?

My two cents.

Note: If the highlight method wording is not clear enough, someone
should send a LC comment about it.

-- 
Regards,
 Benoit   mailto:benoit@itedo.com

This e-mail and any attachments are confidential and may be protected
by legal privilege. If you are not the intended recipient, be aware
that any disclosure, copying, distribution or use of this e-mail or
any attachment is prohibited. If you have received this e-mail in
error, please notify us immediately by returning it to the sender and
delete this copy from your system. Thank you for your cooperation. 


Wednesday, June 14, 2006, 7:47:04 PM, Lofton Henderson wrote:

> At 04:07 PM 6/14/2006 -0700, Galt, Stuart A wrote:
>>Hello,
>>
>>My confusion may have started because in step 2 I remove the
>>highlight on "C" but it still remains highlighted.  I assume that this
>>is because of the nested structure in this CGM and the previous call to
>>highlight "B" (that contains "C").

> FWIW, I still would have expected that "C" (and all that it contains) 
> should have gone "off".  The spec says:

> =====
> state of type boolean

>      A true value will highlight the nodes, whereas false will remove the
> highlight.
> =====

> It doesn't say, "...; false will remove highlight, but ONLY IF it was 
> previously set explicitly on that node by a call to highlight() with that
> node in the argument list."  (If that's what's meant, clarification of the
> wording might be in order.)

>>[...]
>>If highlighting is a state system and that when you turn on highlighting
>>for circle B.  The entire contents of B (which includes "C" and "D") is
>>highlighted.

> If we intend that "C" -- whose contents were incidentally highlighted 
> because they are also contents of "B", which received the call 
> "highlight(B, true)" -- should stay highlighted when it the user tries to
> turn it off with "highlight(C, false) ... that seems a strange and 
> surprising result to the unwary!  At the very least, some explanation in
> the text is in order, if that is the intention.  Some people would not
> guess this behavior without some better hints in the text.

> Thoughts?

> One small follow up on my earlier comment...

> [...]
>> > Maybe that would be a good clarification comment -- that
>> > highlight(someObject) is identical to:  #id(someObject,
>> > newHighlight) or #id(someObject, addHighlight).  Which one?
>> > I'd say the 2nd, 'addHighlight'.  Thoughts?

> Oops, about my statement "highlight(someObject, true) is identical to ..."

> The problem with such an example is that there is no symmetrical "off"
> example.  I.e., there is no fragment "#id(someObject,...)" that is 
> equivalent to "highlight(someObject, false)."  There is #id(*, 
> clearHighlight), but only the wildcard "*" (all objects) is allowed -- you
> can't name a single object in place of "*".

> -Lofton.