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

[Lofton Henderson <lofton@rockynet.com>]

[1 of 2]

It's getting pretty hard to keep replying on this thread.  Let me summarize 
a couple of thoughts first, then address 1-2 specific details in a 
subsequent message.

Dieter is proposing a possibly useful interpretation of what 
"getAppStructureAttr" returns in the case that no explicit value of the 
relevant ApsAttr (visibility, interactivity, etc) has been set on the 
queried Aps.

I am concerned, because it is a divergence from the way standard (W3C XML) 
DOM works in those cases.  It is my view that we should deviate as little 
as possible from how standard DOM works (and that matter, SVG DOM) unless 
there is a really compelling reason -- these have been well-tried, and seem 
to work.  Conversely, I don't yet fully understand the implications of some 
of the proposed deviations -- both short term (knock-on effects with other 
elements, methods, etc) and long term (what if we decide to expand beyond 
our limited, starter-kit DOM?).

Benoit suggests, I think, that we should stick for now with how WebCGM DOM 
is currently defined (similar to XML DOM), and how inheritance works 
(currently, similar to SVG inheritance).  If user/implementor feedback show 
big deficiencies, we can revisit and address them then.

I like Benoit's suggestion.

-Lofton.

At 11:11 PM 4/27/2005 +0200, =?us-ascii?Q?Dieter__Weidenbruck?= wrote:
>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>