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: Re: [cgmo-webcgm] ISSUE: Object behaviors


Dieter,

Thanks for a thoughtful and complete proposal.  I could support its basic 
shape.  IMO, it covers all of the options that a user might want.  I wonder 
if our (other) implementors are comfortable with it?

A couple of comments ....

At 11:08 AM 6/17/2005 +0200, =?us-ascii?Q?Dieter__Weidenbruck?= wrote:
>[...]
>3. New Proposal
>This is my proposal, it comes in two variants:
>
>Variant A:
>objBehavior ::= navTerm ("_" highlightTerm)? ("_all")? |
>                     highlightTerm ("_all")?
>navTerm ::= full | zoom | move
>hightlightTerm ::= highlight | highlightadd
>
>
>Build the actual objectBehavior from a navigation term, a highlighting term,
>and the
>"all" keyword as desired.
>Note that in this variant "highlight" and "highlight_all" could be build
>preserving
>full backward compatibility.

Except the identical keywords "highlight" and "highlight_all" would now 
actually behave differently, according to WebCGM 1.0 2nd Release.  Old 
highlight and highlight_all would correspond to new highlight+full and 
highlight+full+all.

I generally don't like changing meanings like that and creating 
incompatibilities.  If the TC doesn't want to do that, maybe we could have 
a slightly modified strategy that would avoid it.  For example, part of 
such a strategy could be to deprecate all three of the old behaviors, and 
change the syntax slightly to distance it from the old.  E.g., could be to 
use "+" as the joiner, instead of "_".  Then highlight_all would be clearly 
"old".  Remaining problem:  the highlight keyword, when alone by 
itself.   Options:

i.) Maybe change the highlight keyword itself? (hilite, hglt, emphasize, ...)
ii.) Replace the highlight and highlightadd (which you propose below) 
with:  newHighlight, addHighlight
iii.) Leave keyword the same, redefine semantics, and implementations would 
have rely on WebCGM ProfileEd to sort its semantics (could this be 
problematic with DOM transactions?  I haven't thought it through yet).

#iii is more or less implicit in your proposal (by not mentioning it 
otherwise).  I think I like #ii, in combination with new syntax:  e.g., 
zoom+newHighlight

More below...

>Variant B:
>objBehavior ::= navTerm ("_" highlightTerm)? |
>                     highlightTerm
>navTerm ::= full | zoom | move
>hightlightTerm ::= highlight | highlightadd
>
>
>Build the actual objectBehavior from a navigation term and a highlighting
>term as desired.
>This variant doesn't use the keyword "all" anymore.
>
>"All" only makes a difference if the object is specified by name. In WebCGM
>1.0, we
>had the following:
>#name(myName,highlight)         highlight the first object with this name
>#name(myName,highlight_all)     highlight all objects with this name
>
>To highlight the first object with this name created a random effect based
>on the
>Z order in the file, no good control over this behavior. The most commonly
>used
>variant was "highlight_all". I believe it is safe to assume that if one
>addresses
>objects by name, that "all" is the desired behavior in all cases.
>Hence, we can omit the "all" keyword and assume the associated behavior for
>all
>cases where addressing by name is used.
>Note: This creates a minor issue regarding the definition of "highlight" and
>"highlight_all" in WebCGM 1.0, however, I don't believe that we will break
>applications by combining highlight and highlight_all into one behavior.

I don't have strong feeling about the utility of _all and preserving the 
default "first" behavior.  But changing the keyword sets altogether, using 
"+" joiner, and deprecating the old three, would keep it clean.

>RECOMMENDATION: Variant B.

So it seems like the TC ought to sort out a couple of sub-issues here:

Iss.1:  Keep the _all keyword and the old "first" behavior (default in the 
absence of _all), versus eliminate _all and define objBehavior strings that 
accompany a reference-by-name to mean "all".  E.g., #name(myName, zoom) 
mean to zoom to the rectangle enclosing all objects that match 'myName'.

Iss.2:  deprecate the whole set of 3 old object behaviors, replace 
highlight, use "+" syntax.

So my suggestion for your variant B would look like:

objBehavior ::= navTerm ("+" highlightTerm)? |  highlightTerm
navTerm ::= full | zoom | move
hightlightTerm ::= newHighlight | addHighlight

Regards,
-Lofton.







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