On Wed, Nov 01, 2006 at 04:06:13PM -0800, Yong Chen (yongche) wrote: > I'll do more debugging (including trimming down the size of b.xsd) to > see if I can provide more info. Also did you mean if I fix the > "non-deterministic" issue in xsd file, I'll not run into this problem?
The non-determinism comes from the fact that all your blocks have minOccurs = 0, which means that there is epsilon transition from any state to any other state forward. I think the processing time is due to the elimimation of this mass of e-transition into an even bigger mass of transitions labelled by the element name. Solving the non-determinism by imposing elements structure at least between some blocks would also solve the processing cost. Solving it by renaming element and not touching the structure won't solve it. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
