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

[Benoit Bezaire <benoit@itedo.com>]

DW> Lofton, all,

DW> 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.
DW> 3.1.2.4.2. defines a fallback behavior in cases where the viewcontext does
DW> not exist. We might consider to use the same fallback solution when
DW> doing a getAppStructureAttr on an APS without explicit 'viewcontext'
DW> attribute.
It's an idea, but (personally) I wouldn't change the spec this late
without user feedback. i.e., if we see (after the test suite is done)
that viewcontext and getAppStructureAttr do not make sense the way
they are currently defined, then we change it. Ok?

<snip>

DW> behavior, which can only be on or off. So if there is no interactivity
DW> attribute on the APS, we still have a well defined behavior, which should
DW> be "inherit" (see Benoit's proposal a couple of days ago).
DW> Let's have a look at this situation:
We may be confusing two issues into one (the 'inherit' thread is an
important one -in my opinion-)

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

DW> So the "get" on myObj2 would give you an "undefined" according to your
DW> suggestion. However, according to the inheritance rules, the actual
DW> behavior is off as inherited from myObj1.
DW> So the behavior is not undefined, just the attribute is not there.
DW> Shouldn't we return "inherit" in such a case?
Good question... but if we look at other existing technologies that do
use inheritance, say HTML and SVG; the answer would be no, an empty
string is returned.

Regards,

-- 
 Benoit   mailto:benoit@itedo.com