RE: Re[2]: [cgmo-webcgm] ISSUE: what does 'get..' return? [2 of 2]

[Dieter Weidenbruck <dieter@itedo.com>]

Hi Lofton,

we are close.

LH> Here is our conceptual disagreement.  Because the 3.2.2.9 model (above)
LH> says "Inherited: yes", you are interpreting that as meaning that the
LH> initial value for an unspecified attribute must be 'inherit'.  I don't
LH> think that necessarily follows.  IMO, our model currently works
LH> fine this way:
LH>
LH> 1.) if explicitly set value on particular node, that is it for
LH> both display
LH> and DOM query (no dispute here);
Agreed.

LH> 2.) if no explicitly set value on particular node, including on any
LH> ancestors, then "Initial value" is used for display ("Initial
LH> value: on"
LH> rules);
Agreed.

LH> 3.) if no explicitly set value on particular node, but explicit on an
LH> ancestor, then that ancestor value used for display ("Inherited: yes"
LH> rules, overrides initial value);
see comment below.

LH> 4.) if no explicitly set value on particular node, DOM query returns
LH> "undefined" (standard DOM rule)
LH>
agreed. The behavior is inherit then, though.


I guess my confusion is based on my lack of understanding, what "initial
value"
means.
I have no problem with 4.), a programmer then knows that he has to walk up
the
tree to compute the actual behavior, if there is any specified on ancestors.

Questions:
- initial value is used until an explicit value is set using a DOM call,
right?
- assume the following situation:
   BEGAPS 'first'
     'visibility' on
     BEGAPS 'second'
     ENDAPS;
   ENDAPS;

  first is visible, second as well.
  DOM get call on second returns "undefined" according to 4.)
  Now assume a "set" call on "second"
	set visibility to "off"
  DOM get call on second now returns "off".

  How do I return to the initial state?
  I can delete the attribute, no problem.
  Then there may be one out of two situations:
	- ancestor has set value and controls visibility of "second" from there on
	- no ancestor with set value.

  Does the latter case imply that "initial value" will be used,
	- after opening the file without modifications
	- after deleting a previously set attribute on the APS AND no ancestor has
a set value
	- after deleting an attribute read from the WebCGM file AND no ancestor has
a set value
- how do I set the "undefined" state from within an XCF?
   BEGAPS 'first'
     'visibility' on
   ENDAPS;

  I can set visibility="on" or visibility="off". How do I delete the
attribute, or
  in other words, how do I set this APS to inherit its behavior from its
ancestors?

Sorry for my confusion, probably I should read more about "initial value"
first.

Regards,
Dieter



LH> >That's all we can say about
LH> >this particular APS without looking at the ancestors.
LH>
LH> Agreed, must consider ancestors (but of course you look at all
LH> nodes when
LH> you initially build the structure tree).
LH>
LH> >I take it that "inherit" on the root element means "on"
LH>
LH> I haven't heard that last condition suggested before.  To me,
LH> it seems a
LH> special and quirky condition -- a different initial value for
LH> root element
LH> versus all other elements.
LH>
LH>
LH> >So the spec says, that the value may be inherited:
LH> >"Inherited: yes"
LH> >however, it does not spell out how to do this on the APS.
LH>
LH> We probably wouldn't be having this discussion, if it had all
LH> been spelled
LH> out clearly in the spec!  Whether or not you like the model of
LH> #1-#4 above,
LH> do you think it is spelled out clearly there (above)?
LH>
LH>
LH> >So the wording could be changed in two ways:
LH> >1. add verbiage explaining that "no attribute on APS" means
LH> "inherit", or
LH>
LH> When you say "means 'inherit'", I think what you're saying is that
LH> 'inherit' should be the initial value, and it means that
LH> ancestor values
LH> are inherited for graphical display, but 'inherit' is returned for DOM
LH> query answer.  I'm not sure that this is necessary (or preferable).
LH>
LH> >2. add "inherit" as a legal value
LH>
LH> This might be useful, in any case, for the sort of scenario I
LH> suggested in
LH> an earlier message.
LH>
LH> >Am I overcomplicating this?
LH>
LH> To my way of thinking, the simplest way forward is to emulate
LH> relevant bits
LH> of similar successful specifications, rather than inventing all
LH> the details
LH> on our own.  ***Unless we really fail our user requirements!***
LH>  Which I
LH> don't yet see that we're doing.
LH>
LH> Regards,
LH> -Lofton.
LH>
LH> p.s.  I'm curious -- does anyone know of any DOM-like precedents for
LH> supporting *two* flavors of inquiry against an Attribute, "defined" and
LH> "realized"?
LH>
LH>
LH>