atom feed10 messages in org.oasis-open.lists.cgmo-webcgmRe: [cgmo-webcgm] WebCGM traversal ro...
FromSent OnAttachments
Benoit BezaireOct 7, 2004 8:31 am 
Lofton HendersonOct 7, 2004 4:41 pm 
Benoit BezaireOct 8, 2004 5:14 am 
Lofton HendersonOct 8, 2004 6:41 am 
Forrest CarpenterOct 8, 2004 7:26 am 
Kevin O'KaneOct 8, 2004 8:37 am 
Cruikshank, David WOct 8, 2004 9:41 am 
Forrest CarpenterOct 8, 2004 12:46 pm 
Benoit BezaireOct 8, 2004 1:18 pm 
Dieter WeidenbrueckOct 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,