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

[Dieter Weidenbruck <dieter@itedo.com>]

Lofton, all,

please find some comments inline.

LH> -----Original Message-----
LH> From: Lofton Henderson [mailto:lofton@rockynet.com]
LH> Sent: Wednesday, April 27, 2005 4:10 PM
LH> To: cgmo-webcgm@lists.oasis-open.org
LH> Subject: [cgmo-webcgm] ISSUE: what does 'get..' return?
LH>
LH>
LH> Hi WebCGM TC,
LH>
LH> I'm working on the DOM test case for ApsAttr 'viewcontext', and
LH> think that
LH> we ought to clarify something about the 'get...' methods.
LH> Specifically I'm
LH> working with getAppStructureAttr, section 5.7.6 (but this
LH> probably applies
LH> somewhere else as well).
LH>
LH> Let's consider the case of 'viewcontext' first.  Section 3.2.2.2 says
LH> "Initial value: none", which is reasonable.  If I
LH> getAppStructureAttr on an
LH> APS where there is no explicit 'viewcontext' ApsAttr, then the answer
LH> should be "undefined" (see side-issue about "undefined" below).
LH>  This is
LH> the way DOM2 works, so we should stick with that unless we have a
LH> compelling reason to deviate.
3.1.2.4.2. defines a fallback behavior in cases where the viewcontext does
not exist. We might consider to use the same fallback solution when
doing a getAppStructureAttr on an APS without explicit 'viewcontext'
attribute.


LH>
LH> Now let's consider the case of 'interactivity'.  Section 3.2.2.10 says
LH> "Initial value: on".  If I getAppStructureAttr on an APS where
LH> there is no
LH> explicit 'viewcontext' ApsAttr, then should the answer should be
LH> "undefined", or should it be "on"?  Benoit and I have discussed it a
LH> bit.  The answer should be "undefined".  Here's our reasoning:
Should this read "...on an APS where there is no explicit 'interactivity'
ApsAttr" ?

LH>
LH> 1.) when we say "initial value", we really mean initial
LH> graphical effect in
LH> an (interactive) graphical viewer, in the case that a given APS doesn't
LH> have an explicit occurrence of the 'interactivity' ApsAttr.
LH>
LH> 2.) we do not mean default in the sense of an XML attribute
LH> default, which
LH> would be DOM-visible in the structure tree.
LH>
LH> 3.) SVG considered and discussed this point ever since 1.0, and
LH> has made
LH> this same distinction.
LH>
LH> 4.) If we agree that it is not an XML-attribute-like default,
LH> but rather an
LH> initial graphical effect, then DOM2 is clear that it should not
LH> be returned
LH> by calls to the "get..." methods.  Rather, the value
LH> DOM-visible value is
LH> "undefined".
LH>
LH> Unless someone disagrees with this interpretation, I think it would be
LH> useful to clarify this in the spec -- it would have saved me a bunch of
LH> head scratching and thinking about it.
>From a programmer's point of view, there is a need to determine the actual
behavior, which can only be on or off. So if there is no interactivity
attribute on the APS, we still have a well defined behavior, which should
be "inherit" (see Benoit's proposal a couple of days ago).
Let's have a look at this situation:

...
BEGINAPS myObj1
	APSATTR interactivity off
BEGAPSBODY
	BEGINAPS myObj2
		BEGAPSBODY
			...
	ENDAPS
ENDAPS

So the "get" on myObj2 would give you an "undefined" according to your
suggestion. However, according to the inheritance rules, the actual
behavior is off as inherited from myObj1.
So the behavior is not undefined, just the attribute is not there.
Shouldn't we return "inherit" in such a case?

Regards,
Dieter

LH>
LH> Side-issue: binding of "undefined".  In JavaScript, what do we
LH> want to be
LH> the value for an "undefined" return from getAppStructureAttr?
LH> Would it be
LH> the JavaScript 'null' reserved keyword (seemingly the most obvious
LH> choice)?  Or would it be an empty string?  Or ...?
LH>
LH> Regards,
LH> -Lofton.
LH>
LH>
LH>
LH>