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

[Lofton Henderson <lofton@rockynet.com>]

At 06:50 PM 4/27/2005 +0200, =?us-ascii?Q?Dieter__Weidenbruck?= wrote:
>Lofton, all,
>please find some comments inline.

Thanks, Dieter.  I'll try to add some comments of my own.  This is getting 
complicated.  Since you refer to Benoit's "inherit" message, let me make 
some comments on that first, then on your present message.

At 11:13 AM 4/20/2005 -0400, Benoit Bezaire wrote:
>   The 'visibility' and 'interactivity' attributes, currently only have
>   values of: on | off.
>
>   We think that's not sufficient. We should at least specify what it
>   means _not_ to set the 'visibility' attribute. I wouldn't want
>   authoring tools to set 'visibility' to true on all APS to make them
>   visible. The default authoring tool behavior should be not to set
>   the attribute, unless the user explicitly sets it to on | off.
>
>   I think we've said (on calls or at FTF meetings) that if the
>   attribute is not set, the APS is visible. Then my question is, what
>   should be displayed in the following case:
>
>   BEGAPS 'first'
>     'visibility' off
>     BEGAPS 'second'
>     ENDAPS;
>   ENDAPS;
>
>   Do we see 'second' or not? I want the answer to be 'second' is not
>   displayed.

I agree, we do NOT want to see 'second'.  But...

>However, the spec as it is now, is underspecified and
>   needs to be clarified.

Clarified perhaps, but I think it does what we want.  3.2.2.9 says:
Initial value:  on
Applies to:  layer, grobject, para, subpara
Inherited:  yes

I understand this as meaning that 'second' is invisible -- the nearest 
explicit setting on an ancestor node, 'off', inherits to its descendents, 
overriding the "initial value".  I.e., initial value only pertains if there 
is not an explicit, inherited value set on an ancestor.

>   I would like for us to state that if 'visibility' or 'interactivity'
>   is not specified, it's value is then 'inherit'. The CSS spec defines
>   the 'inherit' property as: For a given element, the property takes
>   the same computed value as the property for the element's parent.
>   This would generate the result I'm looking for.

I'm reluctant to accept this yet, because I'm not sure it's needed.  I 
understand and agree with the effect that you want.  But I think it's 
already there in the spec.  Your proposal also raises a question:  if all 
elements in the picture have 'inherit' initial value, then are they visible 
or not?  I.e., does every WebCGM instance have to explicitly set 'visible' 
on the root element?  Or do we have to invent some artifice to make the 
value 'inherit', but make everything appear visible?

For comparison, I went looking at SVG11:
http://www.w3.org/TR/SVG11/painting.html#VisibilityProperty

Note that 'inherit' is a valid value, but the "Initial value" is 'visible', 
and the attribute is inherited.  Just like we now have in WebCGM.

>If the group
>   agrees with this, we then need to decide on something else...
>
>   Should we allow to explicitly set 'visibility' and 'interactivity'
>   to 'inherit? Yes or No?

Although I don't feel strongly, I can see the value, for a scenario like 
this.  Initially, everything is visible.  A node X is set to 
'invisible'.  Other stuff happens.  Later on, we want node X to have the 
same visibility as the branch of the tree it is in.  Yes, we could use DOM 
to go up the tree and find the first explicit setting on an ancestor.  But 
it would be easier to just set node X to 'inherit'.

On to Dieter's comments...

At 06:50 PM 4/27/2005 +0200, =?us-ascii?Q?Dieter__Weidenbruck?= wrote:
[...]
>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.
>3.1.2.4.2. defines a fallback behavior in cases where the viewcontext does
>not exist. We might consider to use the same fallback solution when
>doing a getAppStructureAttr on an APS without explicit 'viewcontext'
>attribute.

I'm no DOM expert, but I want to be very careful to go down this road, 
because IMO it diverges from DOM (as well as from how SVG has done it).

It seems to me that we're potentially talking about two different things: 
first, the Document Object -- a tree that is initially defined according to 
DOM rules by data that occurs in the WebCGM document instance (+ XCF); and 
second, a "viewer object", which tells us not about the WebCGM document but 
about the viewed picture.

>LH> Now let's consider the case of 'interactivity'.  Section 3.2.2.10 says
>LH> "Initial value: on".  If I getAppStructureAttr on an APS where
>LH> there is no
>LH> explicit 'viewcontext' ApsAttr, then should the answer should be
>LH> "undefined", or should it be "on"?  Benoit and I have discussed it a
>LH> bit.  The answer should be "undefined".  Here's our reasoning:
>Should this read "...on an APS where there is no explicit 'interactivity'
>ApsAttr" ?

Yes.  (Sorry, I'm working on a viewcontext test, but jumping off from 
Benoit's interactivity test.)


>LH>
>LH> 1.) when we say "initial value", we really mean initial
>LH> graphical effect in
>LH> an (interactive) graphical viewer, in the case that a given APS doesn't
>LH> have an explicit occurrence of the 'interactivity' ApsAttr.
>LH>
>LH> 2.) we do not mean default in the sense of an XML attribute
>LH> default, which
>LH> would be DOM-visible in the structure tree.
>LH>
>LH> 3.) SVG considered and discussed this point ever since 1.0, and
>LH> has made
>LH> this same distinction.
>LH>
>LH> 4.) If we agree that it is not an XML-attribute-like default,
>LH> but rather an
>LH> initial graphical effect, then DOM2 is clear that it should not
>LH> be returned
>LH> by calls to the "get..." methods.  Rather, the value
>LH> DOM-visible value is
>LH> "undefined".
>LH>
>LH> Unless someone disagrees with this interpretation, I think it would be
>LH> useful to clarify this in the spec -- it would have saved me a bunch of
>LH> head scratching and thinking about it.
> >From a programmer's point of view, there is a need to determine the actual
>behavior, which can only be on or off. So if there is no interactivity
>attribute on the APS, we still have a well defined behavior, which should
>be "inherit" (see Benoit's proposal a couple of days ago).

Again, I'm nervous to go this way (that "getApsStructureAttr returns 
actual, computed behavior"), because it seems to me that the actual 
behavior is not about the document object but rather about a viewer/viewed 
object.  (If I'm getting in over my head here, tell me!)

Which one is it that we are standardizing?

Btw, I believe that the WebCGM DOM application can deduce the actual 
behavior of any node, using a document-object approach, and knowing the 
rules of that document's grammar (inheritance etc).  But if it takes the 
viewer-object approach, it cannot deduce what is actually in the WebCGM 
document object (+XCF).  Is this true?

>Let's have a look at this situation:
>
>...
>BEGINAPS myObj1
>         APSATTR interactivity off
>BEGAPSBODY
>         BEGINAPS myObj2
>                 BEGAPSBODY
>                         ...
>         ENDAPS
>ENDAPS
>
>So the "get" on myObj2 would give you an "undefined" according to your
>suggestion. However, according to the inheritance rules, the actual
>behavior is off as inherited from myObj1.
>So the behavior is not undefined, just the attribute is not there.
>Shouldn't we return "inherit" in such a case?

I don't know.

But, having gotten "undefined" answer, and knowing the rules of the WebCGM 
document object (inheritance etc), I could use DOM methods to deduce that 
the actual behavior is "off" (because of that explicit setting on an ancestor).

Am I overlooking something here?

-Lofton.