OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re[2]: [cgmo-webcgm] WebCGM traversal routines


Hi Lofton,

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.

Cheers,

-- 
 Benoit   mailto:benoit@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:
>>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;

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!

LH> -Lofton.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]