atom feed12 messages in org.oasis-open.lists.cgmo-webcgmRe[2]: [cgmo-webcgm] ISSUE: what doe...
FromSent OnAttachments
Lofton HendersonApr 27, 2005 7:10 am 
Benoit BezaireApr 27, 2005 8:53 am 
Lofton HendersonApr 27, 2005 9:29 am 
Dieter WeidenbruckApr 27, 2005 9:49 am 
Lofton HendersonApr 27, 2005 11:13 am 
Benoit BezaireApr 27, 2005 12:02 pm 
Benoit BezaireApr 27, 2005 12:36 pm 
Dieter WeidenbruckApr 27, 2005 1:09 pm 
Benoit BezaireApr 27, 2005 1:59 pm 
Dieter WeidenbruckApr 27, 2005 2:10 pm 
Lofton HendersonApr 27, 2005 2:59 pm 
Benoit BezaireApr 28, 2005 6:09 am 
Subject:Re[2]: [cgmo-webcgm] ISSUE: what does 'get..' return?
From:Benoit Bezaire (ben@itedo.com)
Date:Apr 27, 2005 12:02:30 pm
List:org.oasis-open.lists.cgmo-webcgm

DW> Lofton, all,

DW> please find some comments inline.

LH>> -----Original Message----- LH>> From: Lofton Henderson [mailto:lof@rockynet.com] LH>> Sent: Wednesday, April 27, 2005 4:10 PM LH>> To: cgmo@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,