[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Re[3]: [cgmo-webcgm] XCF and "inherit" value
Hi Forrest, from the metafile interface it is easy to go to any picture in a multi-picture file. So it is no problem to handle the case that another non-WebCGM profile allows for multiple pictures. Now in the CGM sense pictures have nothing to do with each other, so the DOM should reflect that. An APS in Picture 1 is not related in any other way to an APS in Picture 2 than that it resides in the same file. Regards, Dieter > -----Original Message----- > From: Forrest Carpenter [mailto:forrest@sdicgm.com] > Sent: Thursday, May 26, 2005 9:43 PM > To: 'Benoit Bezaire'; cgmo-webcgm@lists.oasis-open.org > Subject: RE: Re[3]: [cgmo-webcgm] XCF and "inherit" value > > > Hi Benoit, all, > > I would like to see the metafile as the root. We are dealing with more and > more multi-picture CGM files. I would not like to be required to use a > different DOM to support these. This may require the WebCGMMetafile to > become a type of WebCGMNode and move the event handlers to the > WebCGMMetafile. If we are ever going to allow multi-picture > CGM's, it would > be better to have the logic in place now. > > Regards, > Forrest > > -----Original Message----- > From: Benoit Bezaire [mailto:benoit@itedo.com] > Sent: Thursday, May 26, 2005 2: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. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]