| From | Sent On | Attachments |
|---|---|---|
| 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: | Forrest Carpenter (forr...@sdicgm.com) | |
| Date: | Oct 8, 2004 7:26:23 am | |
| List: | org.oasis-open.lists.cgmo-webcgm | |
All,
In our implementation the first child is one, because it is the first child in order of the sequence of the cgm file. It makes no sense to make the last child the first child because it is the foremost object in a group. This is backward from the way most tree structures work. In multi-picture files would the first picture become the last picture?
Forrest
At 10:37 AM 10/7/2004, you wrote:
Hi all,
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;
Why would the firstChild of 'group' be 'foo:complexData'?
Obviously looking for your input,
Regards,
-- Benoit mailto:ben...@itedo.com





