Re[2]: [cgmo-webcgm] XCF and "inherit" value

[Lofton Henderson <lofton@rockynet.com>]

Hi Benoit, all --

Close, but not quite there yet...

Benoit, of course I want your answers to my questions (below).  But I'd 
also like to hear some other TC opinions.

At 08:55 AM 5/26/2005 -0400, Benoit Bezaire wrote:
>[...]
>Ok we are getting close. There's a reason why the CSS specification
>uses the word 'element' instead of 'node', and it's because a node is
>not always an element (ex: text node, comment node, doctype node
>etc...). Inheritance only applies to elements, not nodes.
>
>So I'm a bit hesitant to start using the word 'node' or 'element' for
>that matter. 'element' more or less implies XML syntax, which is not
>the case here.

Okay, I have no strong opinion here.  (Actually, "element" is overloaded in 
the WebCGM context, because ISO CGM uses "element" for any individual CGM 
command -- primitives, attributes, delimiters, controls, etc.)

>I disagree that Metafile is the root of the document. I think the
>Picture is the root.

I have some problems with this suggestion, to resolve before I can 
agree.  One  problem is...

Look at Example 5.1a, the paragraph after the box (which you wrote) 
says:  "The in-memory tree representation of this illustration should be 
similar to the illustration found below. It is a simple tree structure with 
a root element WebCGMMetafile, one of the children of the root is a 
WebCGMPicture; the WebCGMPicture contains a Layer and the layer contains an 
Application Structure of type grobject."

Plus, the figures imply that the metafile is the root.  Of the document tree.

>Here's why:
>
>i)   A root must be derived from the node class. This is not the case
>for Metafile.

I don't understand this statement.  Explain please?

>ii)  We currently say for 'parentNode': The parent (immediate ancestor
>node of a node) of this node. All nodes, except WebCGMPicture may have
>a parent.

Aha, I had missed that, and one of my major objections was that I thought 
WebCGMPicture *could* have a parentNode (which the root cannot).

[Btw, editorial, in the sentence, "All nodes, except WebCGMPicture may have 
a parent.":  s/may// , correct?]

>iii) We get to the first picture via getWebCGMDocument().firstPicture,
>not using firstChild.

Yes, that is also how I wrote my test cases (in copycat style).

But on the other hand, look at the first paragraph of 5.7 and the one-line 
descriptions of the node types, after "WebCGM has the following node types 
and children".  That certainly creates the impression that Picture(s) are 
children of Metafile.

>So would you agree on the following wording?
>
>"For the purposes of this inheritance model, Picture (the parent of
>top-level APSs within the picture body) is treated like an APS and is
>the root of the document tree."

I'm in favor of something like this, but:

1.) I want to clarify the questions I asked above.

2.) I want to be sure, if we make such a definition, that we're not somehow 
shooting ourselves in the foot, for adaptation of 2.0 DOM to multi-picture 
metafiles.  (I don't see a specific problem yet.  Does anyone else?)

Finally, if we go that way ... there is text to be cleaned up in several 
places, right?

Regards,
-Lofton.

>--
>  Benoit   mailto:benoit@itedo.com
>
>
>Wednesday, May 25, 2005, 10:25:00 AM, Lofton wrote:
>
>LH> First:  I agree that "inherit" should also be on 'layer'  (as you said,
>LH> don't specialize an attribute-value set depending on the host element).
>
>LH> Second:  I think we all agree what we want to happen for the top-level APS
>LH> or 'layer'.  If it has the value "" (empty string, no set value) or
>LH> "inherit", then it ought to take Initial Value.  What is unclear (to me at
>LH> least) is what the inheritance-model wording currently says about it, 
>i.e.,
>LH> if/how 5.4 currently specifies that.  Because Picture and Metafile nodes
>LH> are ancestors to the top-level APS within the picture.
>
>
>LH> At 03:34 PM 5/24/2005 -0400, Benoit Bezaire wrote:
> >>Hi Lofton,
> >>
> >>I'm catching up to emails... I've read the whole thread and I'm
> >>replying only to this email. I don't think the problem is as
> >>complicated as the thread seems to imply. See inline.
>
>LH> No, I don't think it's particularly complicated, but ... if I was 
>unable to
>LH> determine the answer from 5.4, then that might indicate a problem for a
>LH> naive reader (note, I'm not necessarily claiming to be non-naive!).
>
> >>[...]
> >>LH> Thoughts?  How can we deal with this cleanly?
> >>To me, the thing seems quite simple and I doubt any changes are
> >>required. Here's why?
> >>
> >>(i'm using markup, it's easier :)
> >><metafile>
> >>   <picture>
> >>     <grobject visibility="inherit"/>
> >>   </picture>
> >></metafile>
>
>LH> Let me make it simpler yet:
>
>LH> <metafile>
>LH>     <picture>
>LH>       <grobject id="obj1" ... />
>LH>     </picture>
>LH> </metafile>
>
>LH> This should have exactly the same effect as your example, right?  (And it
>LH> doesn't force us to look at 5.4.2 -- handling of "inherit" value.)
>
>LH> The problem is in 5.4.1.1, #2:  "Otherwise [if not explicitly set], if the
>LH> style attribute is inherited and the Application Structure is not the root
>LH> of the document tree, use the computed value of the parent Application
>LH> Structure."
>
>LH> I understand that you did a first-order adaptation of CSS2 wording (well
>LH> done, at that!) and changed "element" to "APS".  To answer your question,
>LH> No, Picture is not an APS, altho it sort of looks like one for some
>LH> purposes.  (Nor is Metafile, which is the root according to figure 5.1b,
>LH> and is where WebCGMNode.parentNode stops, presumably).
>
>LH> So we need wording that allows the inheritance chain to continue up beyond
>LH> the top-level APS, to the "root of the document tree".  Options:
>
>LH> Opt.1:  s/APS/node/  ?  (Or in original CSS2, s/element/node/).
>LH> Opt.2:  add at end of 5.4.1.1 something like, "For the purposes of this
>LH> inheritance model, Picture (the parent of top-level APSs within the 
>picture
>LH> body) is treated like an APS, and Metafile (the root of the document 
>tree)"
>
>LH> Recommendation:  Opt.2.  Reason:  if those words had been present, I never
>LH> would have asked the question in the first place.
>
>LH> (Note.  We might want to add even more words, or an example involving
>LH> 'visibility' or 'interactivity', the two affected attributes.)
>
>LH> One last comment...
>
>
> >>What is the value of visibility on the <grobject>?
> >> From section: 5.4.1.1 Specified values,
> >>"1. If the style attribute is assigned a value, use it."
> >>Ok, simple enough... so we go to section 5.4.1.2 Computed values,
> >>"See the section on inheritance for the definition of computed values
> >>when the specified value is 'inherit'."
> >>Ok, to section 5.4.2.1 The 'inherit' value,
> >>"the property takes the same computed value as the style attribute for
> >>the Application Structure's parent."
> >>Here it doesn't really matter if you think there is a parent or not,
> >>you will end up that you have to use the initial value, which is "on".
> >>In both cases you will end up with "3. Otherwise use the style
> >>attributes's initial value." of section 5.4.1.1
> >>
> >>BTW, this definition seems to work perfectly fine for HTML and SVG.
> >>And I don't quite see what is the difference between my example above
> >>and this:
> >>
> >><svg>
> >>   <g visibility="inherit"/>
> >></svg>
> >>
> >>The point is that when an implementation is doing the cascade, it
> >>has no choice but to initialize it's style properties structure to the
> >>Initial Values; those values are then cascaded down. So it doesn't
> >>matter if you start at the <metafile> node, the <picture> node, or on
> >>the <grobject> node... as soon as you see 'inherit', it will be
> >>replaced by 'on' (the initial value).
> >>
> >>I tried to adapt the CSS wording to WebCGM when I first wrote it, and
> >>it was me who replaced 'element' with 'Application Structure', which
> >>may be introducing the question of "Is the picture node an APS?. I
> >>think that's the only possible source of confusion on the matter. What
> >>is a good replacement for 'element'?
>
>LH> Yes, as 5.4.1.1, #2, shows, it is the specific use of APS that causes the
>LH> problem, because ancestors of top-level APSs are not APSs.
>
>LH> -Lofton.