[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]