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

[Lofton Henderson <lofton@rockynet.com>]

I see another half-dozen messages on this.  I'm going to have to drop out 
for a bit while I finish some work, but for a last shot let me reply on 
Benoit's terminology comment...

At 09:21 AM 4/28/2005 -0400, Benoit Bezaire wrote:
>[...]
>This thread is not using the right terminology and that's confusing
>me.

Okay.

>I don't like the word "undefined", there is no such word in the
>DOM getAttribute() method.

As I said, that was a paraphrase from the conceptual description in 
Interface Attr (DOM2).  The actual words are "does not exist".  To be precise:

1.) Conceptually, the attribute value "does not exist" in the structure 
tree, if it has not been specified explicitly and does not have an XML-like 
default (i.e., DTD specified).

2.) concretely, it returns a DOMstring always, either non-empty (on, off, 
etc) or empty -- empty in the case of "does not exist".

In my emails, I have been talking about the conceptual view of the 
structure tree, not the concrete result of invoking the getAppStructureAttr 
method.  Sorry for confusing things by using "undefined" instead of "does 
not exist" (or being unclear about conceptual view of structure tree versus 
the concrete result of invoking an inquiry).

>An attribute is either 'specified'
>(explicitly written in the file, attName="value") or has a default
>value (from a schema or DTD, ex: version="2.0").

Conceptually (DOM2):  Specified (explicit), or XML-like (i.e., DTD defined) 
default, or does not exist.


>The DOM getAttribute() method returns an empty string if the attribute
>is not specified or assigned a default value in the DTD. Not
>"undefined".

Agreed.


>Question: Is there a big different between returning an empty string
>or returning the "inherit" string?
>
>To me there isn't since they both mean that the attribute is not
>specified on the object.

There is a difference if 'inherit' is one of the valid values of the 
attribute -- i.e., on | off | inherit.  If "get..." returns 'inherit' in 
the case that the attribute "does not exist", then you are obscuring and 
mixing together two different cases in the structure tree as one.  (The 
case of explicit 'inherit' versus the case of "does not exist".)

As I have said repeatedly, that is not necessary.  As we have currently 
specified it, the attribute value can be inherited by the node in the 
needed case, without specifying that the attribute value (as returned by 
"get..") is 'inherit'.

Finally, about my question on "defined" versus "realized"...

At 09:38 AM 4/28/2005 -0400, Benoit Bezaire wrote:
>[...]
>LH> p.s.  I'm curious -- does anyone know of any DOM-like precedents for
>LH> supporting *two* flavors of inquiry against an Attribute, "defined" and
>LH> "realized"?
>
>You guys sure like to invent new terminology :)

Actually, long before W3C DOM (and WebCGM), some ISO graphics standards had 
APIs to query the state values of the graphics.  They used the keywords 
"set" (what you had specified in the graphic or in the "set.." function), 
and "realized" (what the graphics system actually used in the display).

Terminology confusion aside, I was really just testing the waters, to see 
if we had *strong* use cases for two different flavors of query (and I 
think the use cases should be COMPELLING, not just "would be nice", before 
going in that direction).

>You mean 'specified' and 'inherited' value...

Not necessarily, because additional things happen after inheritance, and at 
least some thread messages have referred to those...

In this thread, without being clear which one we mean, we have variously 
been discussing 'specified', 'inherited', "default", "does not exist", 
"initial value" and various synonyms.  Each of the different terms is a 
slightly different concept (except for the synonyms).

Conceptually, I suspect that some proposals also involve 'computed', 
'used', 'actual' (completing the set of 5.4), without actually explicitly 
intending to do so (e.g., the proposal for a 'get.." return value on 
'viewcontext' when "does not exist" ... that probably involves one or more 
of the latter three).

I agree with you that we have a problem -- it is often unclear to me which 
concept people are advocating for.

>I believe SVG Tiny 1.2
>will be the first specification. They have a getAttribute() (what we
>are familiar with) and it is now introducing a getTrait() (uses strong
>types -strings, boolean, floats, integers and also takes into account
>inheritance).
>
>Note: We have a strong enough language barrier in the group as it is
>(French, German, English...), I think it would help if people would
>use keywords that are found in specifications (CSS, DOM, XML, SVG, CGM
>etc...)

Well then, let's sort out the complete set that is relevant for 
us.  Volunteers?

over-and-out for now,
-Lofton.