OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Hi Benoit,

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

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

Consensus(?):  It seems, from the thread, that everyone can accept "empty string". 

There are a couple of peripheral and IMO orthogonal questions, like "Should we add 'inherit' to the list of settable values of ...?"

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

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

Actually, I didn't think I was re-inventing anything.  Rather, I thought I was explaining what I understand the spec says (and has said for quite some time, as I recall).  To refresh, here is a quote from the spec (about visibility, because it has a clear parallel in SVG) and my 1,2,3,4...
The spec says in 3.2.2.9:
Initial value: on
Applies to: layer, grobject, para, subpara
Inherited: yes
Valid values:  on, off

And my interpretation, in the context of the current question, was (w/ corrected terminology):
1.) if explicitly specified value on particular node, that is it for both display and DOM query (no dispute here);
2.) if no explicitly specified value on particular node, including on any ancestors, then "Initial value" is used for display ("Initial value: on" rules);
3.) if no explicitly specified value on particular node, but explicit on an ancestor, then that ancestor value used for display ("Inherited: yes" rules, overrides initial value);
4.) if no explicitly specified value on particular node, DOM "getAppStructureAttr" query returns empty string  (standard DOM rule)
If we reverse the order of #2 and #3, we get:

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

Isn't 1-3 above now the same as 1-3 in 5.4.4.1?  (I think revised 1-4 above better and more cleanly expresses what I was trying to get at.)  Well, not exactly.  5.4.1.1, #2 says that the Computed Value inherits.  As I understand it, CV would be the same as Specified Value for 'visibility' (and 'inheritance').

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

I'm not taking a position quite yet on whether the specifiable "inherit" value is desirable or not, for some "style attributes", for some ApsAttrs, etc.  There is an interesting use case that both Dieter and I each proposed separately (for 'visibility').  (Question.  Is it interesting enough to justify the cost of implementing it?).  However, that use case aside, I am I am not yet convinced that the value "inherit" adds anything to the basic inheritance model or improves its working, especially for the ApsAttrs like 'visibility'.  My doubt is in fact reinforced by these words from 5.4.2.1:  "...the inherit value can be used to strengthen inherited values."  (Strengthen?)

(Btw, it seems that where Dieter really wants "inherit" is in an XCF use case.  In DOM scripts, it looks like we got all necessary capabilities by properly applying the inheritance model, and sometimes using the removeAppStructureAttr method.  So an explicit "inherit" value in the XCF would be used to accomplish the same thing that you can do with the removeAppStructureAttr method in a DOM script.  Is this correct?)

Regards,
-Lofton.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]