WebCGM traversal routines

[Benoit Bezaire <benoit@itedo.com>]

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:benoit@itedo.com