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 transition.
> 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
> code.
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 minOccurs="0"
- 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
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
