Re: [xml] bug 362989

Hi Daniel,

Thanks a lot, I do appreciate your effort, time, and kindness.

Also wanted to let you know, it's not that I didn't want to spend my
time on it, you know I'm using libxml2 seriously. Actually I've been
debugging this issue for a long time, including reading libxml source
code, trimming down the xsd file for all kinds of testings. Trust me, I
did spend lots of time on it.

As for my xsd file, I knew it had "non-deterministic" problem (that is,
name uniqueness violation), I used a Java xsd validator and it showed me
the problem. But libxml2 should show me the same error (instead, it went
into infinite loop), that's something I want to fix.

Yes the xsd file is auto-generated, your comments remind me to make it
more readable (or user-friendly). I'll see if I can do something about

Again, thanks a lot. I'll fix my xsd issue. And where can I see the bug
fix and optimization code? (in the bugzilla)?

Yong Chen

-----Original Message-----
From: Daniel Veillard [mailto:veillard redhat com] 
Sent: Wednesday, November 01, 2006 7:07 AM
To: Yong Chen (yongche)
Cc: xml gnome org
Subject: Re: [xml] bug 362989

On Tue, Oct 31, 2006 at 08:00:59PM -0500, Daniel Veillard wrote:
On Tue, Oct 31, 2006 at 02:25:49PM -0800, Yong Chen (yongche) wrote:
This is the epsilon transition elimination in the graph of 
Each time someone tried to point out that the 
implementation of this 
function was broken it was something else, it's just where 
the problem 
usually show up, the error being the construction of the graph 
automata. Of course the construct in the automata are a bit 
more complex than in the book.
  It is not trivial, it takes serious concentration and 
time to really 
understand where the problem comes from. The bigger the 
example, the 
bigger the automatas, the more time it takes. You may start to 
understand why I insist on getting a reduced problem.

  I spent 3 hours on the problem, a large part of it trying 
to understand your schemas. And I found a bug, really not 
obvious, and a couple of optimizations.

  I would also like to raise the point of the 'niceness' of 
that schemas.
It seems to me trying to understand the semantic of that is 
near impossible,
  <xs:group ref="optional_group_4" minOccurs="0" 
maxOccurs="1"/> looks 
like automatically generated schemas with names without semantic 
constant references to labels, making even harder to get 
the full picture.
It's a bit like asking to debug code which was 
automatically generated 
i.e. even more painful than when you can extract the 
semantic of the 

  I guess you will appreciate the fact that I think I fixed the bug:

paphio:~/XML -> xmllint --timing --noout --schema 362989.xsd test.xml
362989.xsd:23: element complexType: Schemas parser error : 
complex type 'access-list_type': The content model is not determinist.
WXS schema 362989.xsd failed to compile
Compiling the schemas took 1195 ms
Parsing took 0 ms
Freeing took 0 ms
paphio:~/XML -> 

  I guess you now need to fix your schemas, it it not 
deterministic, and hence should be rejected by any correct 
XSD implementation. Let's say I really did *not* enjoy 
debugging in your schemas, still I'm kind and will give you 
the reason leading to my believing it's broken:
    - see the content model for access-list_type
    - notice how all groups direct or derived use minOccurs="0"
    - notice how all elements in the content model also have 
    - notice that element "src_addr" is defined by both
      block_group_18 and block_group_3
    - block_group_18 is referenced by block_group_17
    - block_group_3 is referenced by block_group_2
    - block_group_2 is referenced by access-list_type
    - block_group_17 is referenced by access-list_type

 so this can't be determinist, your schemas is broken


Red Hat Virtualization group
Daniel Veillard      | virtualization library
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]