|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:||Lofton Henderson (lof...@rockynet.com)|
|Date:||Oct 7, 2004 4:41:50 pm|
Very quickly, a couple thoughts ...
I have been thinking all along that First Child was in the XML tree-order sense, not in the graphical display order sense. Reasons:
** in talks and tutorials, we have been comparing structured WebCGM directly to XML-tagged graphical data. That has fostered the sense that the WebCGM tree is a straightforward binary equivalent to an XML tree.
** I haven't thought it through yet, but what about mixed applications that deal with structured WebCGM instances and XML Companion files? Isn't the order of the XML data going to be "XML tree order"? Isn't it going to be confusing to have the CGM tree be "graphical display order"?
** We see people trying to make converters, WebCGM to SVG (using the latter as a downstream display format). At first thought, it would sure seem chaotic to have the tree orders be the reverse of each other!
** If First Child is "top of display pile", does it interact with visibility?
Note one other embedded comment below...
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;
This is your internal memory representation of an XML Companion File. It is not the syntax of the companion file instance. The latter would be something like:
<group ... xmlns="..." xmlns:foo="..." /> <foo:simpleData ...> ... </foo:simpleData> <foo:complexData ...> ... </foo:complexData > </group>
I.e., the syntax of the XML Companion File is really XML syntax. (Yes, I know my example syntax probably deviates from exactly what rules we designed for XMLCompFile, but you get the point, and I don't have time to look up our exact syntax).
Why would the firstChild of 'group' be 'foo:complexData'?
It would be very surprising if First Child of 'group' were foo:ComplexData!