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

[Benoit Bezaire <benoit@itedo.com>]

Wednesday, April 27, 2005, 5:11:26 PM, Dieter wrote:

DW> Hi Benoit,

BB>> DW> interactivity/visibility/inheritance:
BB>> LH>> It seems to me that we're potentially talking about two
BB>> LH>> different things:
BB>> LH>> first, the Document Object -- a tree that is initially defined
BB>> LH>> according to
BB>> LH>> DOM rules by data that occurs in the WebCGM document instance
BB>> LH>> (+ XCF); and
BB>> LH>> second, a "viewer object", which tells us not about the WebCGM
BB>> LH>> document but
BB>> LH>> about the viewed picture.
BB>> DW> IMO, a DOM get call does not return the state found in the document,
BB>> DW> it will return the current state.
BB>> DW> Example:
BB>> DW> A WebCGM is read in to memory, then an XML companion file is used to
BB>> DW> set visibility. Of course you want to know about the
BB>> current state of
BB>> DW> the visibility when doing a get.
BB>> DW> Or:
BB>> DW> an APS is read without a viewcontext. A set call is used to
BB>> set one on
BB>> DW> the APS. A subsequent get would retrieve this set
BB>> viewcontext, not the
BB>> DW> state found in the WebCGM.
BB>> The functionality that is defined in the spec does handle both of
BB>> those cases. It is returning the current state, but the 'specified'
BB>> current state, not the 'computed' (i.e., inherited) current state.
DW> I agree that we need the current state, not the computed one.
DW> The current state for me, however, is not "undefined", it is "inherit"
Lofton came up with "undefined", I didn't. I say (like it is written
in the spec today), that the returned value is an empty string.

BB>> DW>> So the "get" on myObj2 would give you an "undefined"
BB>> according to your
BB>> DW>> suggestion. However, according to the inheritance rules, the actual
BB>> DW>> behavior is off as inherited from myObj1.
BB>> DW>> So the behavior is not undefined, just the attribute is not there.
BB>> DW>> Shouldn't we return "inherit" in such a case?
BB>> BB>>Good question... but if we look at other existing
BB>> technologies that do
BB>> BB>>use inheritance, say HTML and SVG; the answer would be no, an empty
BB>> BB>>string is returned.
BB>> DW> So in this case we should still have a value "inherit",
BB>> because that is
BB>> DW> the actual value. Both on or off are explicit behaviors,
BB>> inherit is an
BB>> DW> explicit behavior to inherit from ancestors.
BB>>
BB>> DW> I am also thinking about the following case:
BB>>
BB>> DW> BEGAPS 'first'
BB>> DW>   'visibility' off
BB>> DW>   BEGAPS 'second'
BB>> DW>   'visibility' on
BB>> DW>   ENDAPS;
BB>> DW> ENDAPS;
BB>>
BB>> DW> now I want to set visibility on "second" to inherit. It is
BB>> not possible
BB>> DW> to do so as there is no explicit value. I could only delete
BB>> the attribute.
BB>> At the moment, yes, the only way is to remove the attribute. Is this
BB>> not sufficient?
DW> I could live with this.

DW> The issue for me is the following:
DW> The spec says, as quoted from 3.2.2.9:
DW> Initial value:  on
DW> Applies to:  layer, grobject, para, subpara
DW> Inherited:  yes

DW> However, the value that is returned by the DOM get call, is not on.
DW> The value is not "on", it is "inherit". That's all we can say about
DW> this particular APS without looking at the ancestors.
That's correct.

DW> I take it that "inherit" on the root element means "on"
I think so too, but I couldn't find that particular explanation in the
CSS spec. I'll have to dig some more.

DW> So the spec says, that the value may be inherited:
DW> "Inherited: yes"
DW> however, it does not spell out how to do this on the APS.
I think it does: 5.4.1.1 Specified values

DW> So the wording could be changed in two ways:
DW> 1. add verbiage explaining that "no attribute on APS" means "inherit", or
Yes.

DW> 2. add "inherit" as a legal value
Well adding "inherit" as a legal value doesn't imply that a DOM call
would return that value. A DOM call returns the value of a 'specified'
attribute. Unless an authoring tool is explicitely setting
'visibility' to 'inherit'; a DOM call should return "on" | "off" or ""
(empty string).

DW> Am I overcomplicating this?
No.

-- 
 Benoit   mailto:benoit@itedo.com