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

[Dieter Weidenbruck <dieter@itedo.com>]

Benoit,

I agree with your comments.

> I see three possible solutions:
>
> A) Make Metafile the root: requires for Metafile to derive from Node.
> B) Make Picture the root: requires editorial work.
> C) Remove Metafile interface: could cause some problems for
> addEventListener() and deprecated multi-picture metafile.

I opt for B. Reason:
the editorial work is minor compared to the work required by A and C,
plus the implementation work under way that needs to be changed.
Secondly, if any other profile opts for multi-picture, the door is
still open, that was the intent when we created both metafile AND picture
interfaces.
Third, it is the most logical in the CGM sense: the file is a container,
and it contains a picture that is independent from other pictures.

Regards,
Dieter

> -----Original Message-----
> From: Benoit Bezaire [mailto:benoit@itedo.com]
> Sent: Thursday, May 26, 2005 9:11 PM
> To: cgmo-webcgm@lists.oasis-open.org
> Subject: Re[3]: [cgmo-webcgm] XCF and "inherit" value
>
>
> Thursday, May 26, 2005, 12:39:51 PM, Lofton wrote:
> LH> Hi Benoit, all --
>
> LH> Close, but not quite there yet...
>
> LH> Benoit, of course I want your answers to my questions
> (below).  But I'd
> LH> also like to hear some other TC opinions.
> Same here...
>
> LH> 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.
>
> LH> Okay, I have no strong opinion here.  (Actually, "element" is
> overloaded in
> LH> the WebCGM context, because ISO CGM uses "element" for any
> individual CGM
> LH> command -- primitives, attributes, delimiters, controls, etc.)
>
> >>I disagree that Metafile is the root of the document. I think the
> >>Picture is the root.
>
> LH> I have some problems with this suggestion, to resolve before I can
> LH> agree.  One  problem is...
>
> LH> Look at Example 5.1a, the paragraph after the box (which you wrote)
> LH> says:  "The in-memory tree representation of this
> illustration should be
> LH> similar to the illustration found below. It is a simple tree
> structure with
> LH> a root element WebCGMMetafile, one of the children of the root is a
> LH> WebCGMPicture; the WebCGMPicture contains a Layer and the
> layer contains an
> LH> Application Structure of type grobject."
> Doh! I wrote that section in the "Once upon a time..." timeframe (i.e,
> a lonnnng time ago). Yes, if we say that Picture is the root, the
> graphic and that wording has to change.
>
> LH> 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.
>
> LH> I don't understand this statement.  Explain please?
> Look at the IDL snippet, you'll see that:
>
> interface WebCGMAppStructure : WebCGMNode ...
> interface WebCGMPicture : WebCGMNode ...
> interface WebCGMMetafile ... (doesn't derive from WebCGMNode).
>
> As soon as a class derives from WebCGMNode, it inherits the
> parentNode/firstChild functionality. WebCGMMetafile does not derive
> from WebCGMNode. This is one of the reason why I say that the Picture
> is the root.
>
> >>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.
>
> LH> Aha, I had missed that, and one of my major objections was
> that I thought
> LH> WebCGMPicture *could* have a parentNode (which the root cannot).
>
> LH> [Btw, editorial, in the sentence, "All nodes, except
> WebCGMPicture may have
> LH> a parent.":  s/may// , correct?]
> False... but it should be "All nodes, except WebCGMPicture and
> WebCGMAttr may have a parent."
>
> >>iii) We get to the first picture via
> >>getWebCGMDocument().firstPicture,
> >>not using firstChild.
>
> LH> Yes, that is also how I wrote my test cases (in copycat style).
>
> LH> But on the other hand, look at the first paragraph of 5.7 and
> the one-line
> LH> descriptions of the node types, after "WebCGM has the
> following node types
> LH> and children".  That certainly creates the impression that
> Picture(s) are
> LH> children of Metafile.
> I agree that it does.
>
> >>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."
>
> LH> I'm in favor of something like this, but:
>
> LH> 1.) I want to clarify the questions I asked above.
>
> LH> 2.) I want to be sure, if we make such a definition, that
> we're not somehow
> LH> shooting ourselves in the foot, for adaptation of 2.0 DOM to
> multi-picture
> LH> metafiles.  (I don't see a specific problem yet.  Does anyone else?)
> The deprecated multi-picture feature seems to be the source of the
> problem here. You have to admit that having both Metafile and Picture
> is a waste... they could be combined into one.
>
> LH> Finally, if we go that way ... there is text to be cleaned up
> in several
> LH> places, right?
>
> I see three possible solutions:
>
> A) Make Metafile the root: requires for Metafile to derive from Node.
> B) Make Picture the root: requires editorial work.
> C) Remove Metafile interface: could cause some problems for
> addEventListener() and deprecated multi-picture metafile.
>
> I don't like either options. They all seem to be a lot of work. It
> would be nice to hear from others on this... you and I don't seem to
> be able to find a nice quick fix.
>
> --
>  Benoit   mailto:benoit@itedo.com
>
>
> LH> Regards,
> LH> -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.
>
>
>