|Benoit Bezaire||Oct 7, 2004 8:31 am|
|Lofton Henderson||Oct 7, 2004 4:41 pm|
|Benoit Bezaire||Oct 8, 2004 5:14 am|
|Lofton Henderson||Oct 8, 2004 6:41 am|
|Forrest Carpenter||Oct 8, 2004 7:26 am|
|Kevin O'Kane||Oct 8, 2004 8:37 am|
|Cruikshank, David W||Oct 8, 2004 9:41 am|
|Forrest Carpenter||Oct 8, 2004 12:46 pm|
|Benoit Bezaire||Oct 8, 2004 1:18 pm|
|Dieter Weidenbrueck||Oct 11, 2004 4:55 am|
|Subject:||Re: [cgmo-webcgm] WebCGM traversal routines|
|From:||Benoit Bezaire (ben...@itedo.com)|
|Date:||Oct 8, 2004 5:14:35 am|
Thanks for your opinion. A couple of follow up comments...
In general I think that XML tree-order makes sense since I think the main use case for the traversal routines is to get to the XML metadata. Yes, someone could use the traversal routines on typical APS, but in that case, I don't think the user cares very much about the order. In the case, he's probably counting the number of child nodes or something along those lines.
Could you clarify what you mean by 'If First Child is "top of display pile", does it interact with visibility?', I don't understand, sorry.
-- Benoit mailto:ben...@itedo.com
Thursday, October 7, 2004, 7:42:14 PM, Lofton wrote:
LH> Very quickly, a couple thoughts ...
LH> I have been thinking all along that First Child was in the XML tree-order LH> sense, not in the graphical display order sense. Reasons:
LH> ** in talks and tutorials, we have been comparing structured WebCGM LH> directly to XML-tagged graphical data. That has fostered the sense that LH> the WebCGM tree is a straightforward binary equivalent to an XML tree.
LH> ** I haven't thought it through yet, but what about mixed applications that LH> deal with structured WebCGM instances and XML Companion files? Isn't the LH> order of the XML data going to be "XML tree order"? Isn't it going to be LH> confusing to have the CGM tree be "graphical display order"?
LH> ** We see people trying to make converters, WebCGM to SVG (using the latter LH> as a downstream display format). At first thought, it would sure seem LH> chaotic to have the tree orders be the reverse of each other!
LH> ** If First Child is "top of display pile", does it interact with visibility?
LH> Note one other embedded comment below...
LH> At 11:37 AM 10/7/2004 -0400, Benoit Bezaire wrote:
I have a question regarding the WebCGM DOM traversal routines. I have to admit, this one took me by surprise. Let's take the following WebCGM document snippet as an example:
BEGAPS 'group' ... BEGAPSBODY; BEGAPS 'one' ... ... ENDAPS; BEGAPS 'two' ... ... ENDAPS; BEGAPS 'three' ... ... ENDAPS; BEGAPS 'four' ... ... ENDAPS; ENDAPS;
In your opinion; what is the firstChild of 'group'? Being accustomed to the XML world, I was convinced that the answer would be 'one'; but the existing Isodraw code tells me otherwise, it claims that 'four' is the firstChild. Dieter then explained that 'four' is the firstChild since it's the foremost object of the group. Ok, now it makes sense to me.
We believe (and please correct us if we are wrong) that other private APIs from vendors of this group behave like ours; that a firstChild of a group is not the first child based on file order but instead, the foremost element (visual tree order).
So the question is; do we want to adopt the XML/SVG approach (file order) or stick with current practices of CGM vendors (visual tree order)?
Note: if we do stick with current practices, I would recommend changing the names of these APIs or else they'll be confused with XML/SVG APIs.
I don't know what my preference is on this. I'm some times in favour of the XML/SVG approach (since script writers are used to this) but I could be convinced otherwise since WebCGM files are binary (so your are left with what you see on screen). What is problematic for me are the XML metadata nodes:
BEGAPS 'group' ... BEGAPSBODY; BEGAPS 'foo:simpleData' ... ... ENDAPS; BEGAPS 'foo:complexData' ... ... ENDAPS; ENDAPS;
LH> This is your internal memory representation of an XML Companion File. It LH> is not the syntax of the companion file instance. The latter would be LH> something like:
LH> <group ... xmlns="..." xmlns:foo="..." /> LH> <foo:simpleData ...> LH> ... LH> </foo:simpleData> LH> <foo:complexData ...> LH> ... LH> </foo:complexData > LH> </group>
LH> I.e., the syntax of the XML Companion File is really XML syntax. (Yes, I LH> know my example syntax probably deviates from exactly what rules we LH> designed for XMLCompFile, but you get the point, and I don't have time to LH> look up our exact syntax).
Why would the firstChild of 'group' be 'foo:complexData'?
LH> It would be very surprising if First Child of 'group' were foo:ComplexData!