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: Re[2]: [cgmo-webcgm] ISSUE: what does 'get..' return? [2 of 2]


[2 of 2]

As Dave just said, "I will say that some of the email threads have become 
so convoluted that it's hard to follow who's saying what and when they are 
saying it."  Yep.  I think this one will need a meeting (telecon or f2f) to 
sort out.

That notwithstanding, let me try a couple specific replies to (only) 
Dieter's last comments...

At 11:11 PM 4/27/2005 +0200, Dieter__Weidenbruck?= replied to Beniot (BB>):
>[...]
>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"
>[...]
>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.

If our model is the same as standard DOM, the value is "undefined", unless 
you interpret "Initial value" to be conceptually the same as XML default 
(i.e., DTD default).  In the SVG model, "Initial value" pertains to initial 
graphical effect.  It does not define a default in the XML (DTD / content 
model) sense, hence does not affect DOM query.

>The value is not "on", it is "inherit".

Here is our conceptual disagreement.  Because the 3.2.2.9 model (above) 
says "Inherited: yes", you are interpreting that as meaning that the 
initial value for an unspecified attribute must be 'inherit'.  I don't 
think that necessarily follows.  IMO, our model currently works fine this way:

1.) if explicitly set value on particular node, that is it for both display 
and DOM query (no dispute here);
2.) if no explicitly set value on particular node, including on any 
ancestors, then "Initial value" is used for display ("Initial value: on" 
rules);
3.) if no explicitly set 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 set value on particular node, DOM query returns 
"undefined" (standard DOM rule)

>That's all we can say about
>this particular APS without looking at the ancestors.

Agreed, must consider ancestors (but of course you look at all nodes when 
you initially build the structure tree).

>I take it that "inherit" on the root element means "on"

I haven't heard that last condition suggested before.  To me, it seems a 
special and quirky condition -- a different initial value for root element 
versus all other elements.


>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.

We probably wouldn't be having this discussion, if it had all been spelled 
out clearly in the spec!  Whether or not you like the model of #1-#4 above, 
do you think it is spelled out clearly there (above)?


>So the wording could be changed in two ways:
>1. add verbiage explaining that "no attribute on APS" means "inherit", or

When you say "means 'inherit'", I think what you're saying is that 
'inherit' should be the initial value, and it means that ancestor values 
are inherited for graphical display, but 'inherit' is returned for DOM 
query answer.  I'm not sure that this is necessary (or preferable).

>2. add "inherit" as a legal value

This might be useful, in any case, for the sort of scenario I suggested in 
an earlier message.

>Am I overcomplicating this?

To my way of thinking, the simplest way forward is to emulate relevant bits 
of similar successful specifications, rather than inventing all the details 
on our own.  ***Unless we really fail our user requirements!***  Which I 
don't yet see that we're doing.

Regards,
-Lofton.

p.s.  I'm curious -- does anyone know of any DOM-like precedents for 
supporting *two* flavors of inquiry against an Attribute, "defined" and 
"realized"?




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