[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: FW: Re[3]: [cgmo-webcgm] XCF and "inherit" value
Hi, Something else we should be considering while deciding what is the 'root' of a metafile is the <webcgm> element of the XCF. Whatever we decide the 'root' to be, I think it would make sense to have the <webcgm> element map to it. Meaning that: <webcgm ns:att="some value"/> <ns:elem ..../> ... </webcgm> the "ns" information would be available from the root node. If we don't agree on this, then we'll have severe interop issues as the JS required to extract the namespace information will be different from one vendor to another (and we can't have that). -- Benoit mailto:benoit@itedo.com Friday, May 27, 2005, 10:14:29 AM, Forrest wrote: FC> Hi Dieter, FC> I can work with this either way, but it seems more logical to me to have the FC> WebCGMMetafile as the root and be a type of WebCGMNode. FC> Regards, FC> Forrest FC> -----Original Message----- FC> From: Dieter Weidenbruck [mailto:dieter@itedo.com] FC> Sent: Thursday, May 26, 2005 3:18 PM FC> To: Forrest Carpenter; 'Benoit Bezaire'; FC> cgmo-webcgm@lists.oasis-open.org FC> Subject: RE: Re[3]: [cgmo-webcgm] XCF and "inherit" value FC> Hi Forrest, FC> from the metafile interface it is easy to go to any picture in a FC> multi-picture file. FC> So it is no problem to handle the case that another non-WebCGM profile FC> allows for FC> multiple pictures. FC> Now in the CGM sense pictures have nothing to do with each other, so the DOM FC> should FC> reflect that. An APS in Picture 1 is not related in any other way to an APS FC> in Picture 2 FC> than that it resides in the same file. FC> Regards, FC> 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]