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

[Dieter Weidenbruck <dieter@itedo.com>]

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.
I agree that we need the current state, not the computed one.
The current state for me, however, is not "undefined", it is "inherit"

BB>
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?
I could live with this.

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

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

So the spec says, that the value may be inherited:
"Inherited: yes"
however, it does not spell out how to do this on the APS.

So the wording could be changed in two ways:
1. add verbiage explaining that "no attribute on APS" means "inherit", or
2. add "inherit" as a legal value

Am I overcomplicating this?

Dieter


BB>
BB> --
BB>  Benoit   mailto:benoit@itedo.com
BB>
BB>
BB> DW> Suggestion:
BB> DW> we should have a value "inherit", and then set the default
BB> value to it,
BB> DW> i.e. in case there is no attribute in the file.
BB>
BB> DW> I can see that we could continue to play with "undefined"
BB> values, however,
BB> DW> we describe a well defined behavior, and we want to be able
BB> to set it
BB> DW> explicitely.
BB>
BB> DW> Thoughts?
BB>
BB> DW> Regards,
BB> DW> Dieter
BB>
BB>
BB>