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

[Benoit Bezaire <benoit@itedo.com>]

Hi Lofton,

See inline...

Monday, May 9, 2005, 9:22:21 AM, Lofton wrote:

LH> Hi Benoit,

LH> I have gotten back to this thread, and re-read the whole
LH> thing. After reading the last half-dozen messages between you and
LH> Dieter, I think we actually have answered the initial question of
LH> the thread! At least, it seems that everyone can live with this
LH> answer...

LH> Initial question was:  What does getAppStructureAttr return
LH> for'interactivity', if no value is explicitly specified (WebCGM
LH> instance,applied XCF, or subsequent DOM transactions), and given
LH> that there is no specified default (i.e., in the DTD-like sense)? 

LH> Consensus(?):  It seems, from the thread, that everyone can accept
LH> "empty string". 
I think we should make this a consensus... going once, twice ...

LH> There are a couple of peripheral and IMO orthogonal
LH> questions, like "Should we add 'inherit' to the list of settable
LH> values of...?"
Dieter was asking for this. I think that the implementation cost of
adding 'inherit' is quite low. Forrest also mentioned 'inherit' some
time ago. So let's add it in. Any objections?

Proposal 'visibility' and 'interactivity':
Initial value: on
Applies to: layer, grobject, para, subpara 
Inherited: yes 
Valid values:  on, off, inherit

Note: the XCF DTD has to be updated.

I'm not proposing 'inherit' on other style properties such as
'intensity', 'stroke-color' etc... I think that's a separate issue.

LH> I actually agreed with almost everything that you said about
LH> peripheral issues in the thread, but this puzzled me a bit and
LH> perhaps you can clarify...

LH> At 09:21 AM 4/28/2005 -0400, Benoit Bezaire wrote:
LH> [...]
LH> I don't think we should re-invent an inheritance model with 1,2,3,4.
LH> It is already defined in the spec, please read: 5.4.1.1 Specified
LH> values. That particular wording talks about the CSS style attribute
LH> which should be replaced to WebCGM Style attributes (or something
LH> equivalent), but the concept is there.


LH> Actually, I didn't think I was re-inventing anything. 
LH> Rather, Ithought I was explaining what I understand the spec says
LH> (and has saidfor quite some time, as I recall).  To refresh, here
LH> is a quote fromthe spec (about visibility, because it has a clear
LH> parallel in SVG) andmy 1,2,3,4...The spec says in 3.2.2.9: 
LH> Initial value: on 

LH> Applies to: layer, grobject, para, subpara 

LH> Inherited: yes 

LH> Valid values:  on, off


LH> And my interpretation, in the context of the current
LH> question, was(w/ corrected terminology): 

LH> 1.) if explicitly specified value on particular node, that is
LH> it forboth display and DOM query (no dispute here); 

LH> 2.) if no explicitly specified value on particular node,
LH> including onany ancestors, then "Initial value" is used for
LH> display("Initial value: on" rules); 

LH> 3.) if no explicitly specified value on particular node, but
LH> expliciton an ancestor, then that ancestor value used for
LH> display("Inherited: yes" rules, overrides initial value); 

LH> 4.) if no explicitly specified value on particular node,
LH> DOM"getAppStructureAttr" query returns empty string (standard DOM
LH> rule)

LH> If we reverse the order of #2 and #3, we get:
Yes, we have to switch #2 and #3.

LH> 1.) if explicitly specified value on particular node, that is
LH> it for both display and DOM query (no dispute here);
LH> 2.) if no explicitly specified value on particular node, but
LH> explicit on an ancestor, then that ancestor value used for display
LH> ("Inherited:yes" rules). 
LH> 3.) if no explicitly specified value on particular node,
LH> including on any ancestors, then "Initial value" is used for
LH> display("Initial value: on" rules); 
LH> 4.) if no explicitly specified value on particular node,
LH> DOM"getAppStructureAttr" query returns empty string (standard DOM
LH> rule)

LH> Isn't 1-3 above now the same as 1-3 in 5.4.4.1?
Yes, very close.

LH> (I think revised 1-4 above better and more cleanly expresses what
LH> I was trying to get at.)  Well, not exactly.  5.4.1.1, #2 says
LH> that the Computed Value inherits.  As I understand it, CV would be
LH> the same as Specified Value for 'visibility' (and 'inheritance').
Not 100%, but I don't think it makes a big difference, ex:

BEGAPS 'one'
  ATTR 'visibility' 'on'
  BEGAPS 'two'
    ATTR 'visibility' 'inherit'
    BEGAPS 'three'
    ENDAPS
  ENDAPS
ENDAPS

- 'one' has a clearly specified value of 'on', ok, the APS is visible.
- 'two' has a clearly specified value of 'inherit', but it's 'computed
value' (this is a CSS term) is 'on' (came from 'one'), 'two' is also
visible.
- 'three does not have a specified value, so it inherits the 'computed
value' of its parent which is 'on', not 'inherit'. (small distinction)

LH> Now ... there is a bit more in 5.4 than just that list of
LH> 5.4.4.1. There is the issue of "inherit", which 5.4.2.1 says may
LH> be a valid value of every "style attribute".  At the least, I have
LH> my doubts about the necessity of adding "inherit" values, both to
LH> the proper WebCGM ApsAttrs ('visibility', 'interactivity', ...), as
LH> well as the for-DOM-invented "style attributes" (stroke-weight,
LH> intensity, fill-color, ... ). 

LH> I'm not taking a position quite yet on whether the
LH> specifiable "inherit" value is desirable or not, for some
LH> "style attributes", for some ApsAttrs, etc.  There is an
LH> interesting use case that both Dieter and I each proposed
LH> separately (for 'visibility').  (Question.  Is it interesting
LH> enough to justify the cost of implementing it?).  However, that use
LH> case aside, I am I am not yet convinced that the value "inherit"
LH> adds anything to the basic inheritance model or improves its
LH> working, especially for the ApsAttrs like 'visibility'.  My doubt
LH> is in fact reinforced by these words from 5.4.2.1:  "...the inherit
LH> value can be used to strengthen inherited values."  (Strengthen?)
I think the need for 'inherit' on 'visibility' and 'interactivity' is
demonstrated by Dieter's use case (i.e., XCF). It's true that we have
a missing feature there. If that feature will get use frequently, I
honestly don't know? But the implementation cost is very small, so
let's add it.

LH> (Btw, it seems that where Dieter really wants "inherit" is
LH> in an XCF use case.  In DOM scripts, it looks like we got all
LH> necessary capabilities by properly applying the inheritance model,
LH> and sometimes using the removeAppStructureAttr method.  So an
LH> explicit "inherit" value in the XCF would be used to accomplish the
LH> same thing that you can do with the removeAppStructureAttr method
LH> in a DOMscript.  Is this correct?)
Yes. But I think we should allow for setAppStructureAttr("visibility",
"inherit"), or else the users will be asking questions (i.e, why is it
a valid value in the XCF and not in the DOM API).

It seems like we are close to closing down this thread and these
issues.

-- 
 Benoit   mailto:benoit@itedo.com

 
LH> Regards,
LH> -Lofton.