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]
- From: Lofton Henderson <lofton@rockynet.com>
- To: Benoit Bezaire <benoit@itedo.com>,cgmo-webcgm@lists.oasis-open.org
- Date: Mon, 09 May 2005 07:22:21 -0600
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]