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

[Benoit Bezaire <benoit@itedo.com>]

Wednesday, April 27, 2005, 4:10:13 PM, Dieter wrote:

DW> all,

DW> reply to Lofton's comments, considering Benoit's comments at the same time.

DW> viewcontext:
DW> My recollection from the Cologne f2f meeting is that we talked about
DW> returning the bounding box in case there is no viewcontext.
DW> However, any decision is good for me.

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

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?
BB>>Good question... but if we look at other existing technologies that do
BB>>use inheritance, say HTML and SVG; the answer would be no, an empty
BB>>string is returned.
DW> So in this case we should still have a value "inherit", because that is
DW> the actual value. Both on or off are explicit behaviors, inherit is an
DW> explicit behavior to inherit from ancestors.

DW> I am also thinking about the following case:

DW> BEGAPS 'first'
DW>   'visibility' off
DW>   BEGAPS 'second'
DW>   'visibility' on
DW>   ENDAPS;
DW> ENDAPS;

DW> now I want to set visibility on "second" to inherit. It is not possible
DW> to do so as there is no explicit value. I could only delete the attribute.
At the moment, yes, the only way is to remove the attribute. Is this
not sufficient?

-- 
 Benoit   mailto:benoit@itedo.com

 
DW> Suggestion:
DW> we should have a value "inherit", and then set the default value to it,
DW> i.e. in case there is no attribute in the file.

DW> I can see that we could continue to play with "undefined" values, however,
DW> we describe a well defined behavior, and we want to be able to set it
DW> explicitely.

DW> Thoughts?

DW> Regards,
DW> Dieter