Re: [xml] Schema validity failure for valid document

[Kasimier Buchcik <kbuchcik 4commerce de>]

Daniel Veillard wrote:
> On Tue, Jan 11, 2005 at 03:38:26PM +0100, Kasimier Buchcik wrote:
>
> > > > > is safe. Maybe we can give informations when building the automata,
> > > > > associating an error string to a transition (or a state) and providing
> > > > > back that optional error string from xmlRegExecErrInfo if reached. That
> > > >
> > > > We are already associating the schema type to the transition. But
> > > > having an extra field as a marker per transition would be good.

[...]

>   I just commited the work needed to detect and handle sink states.
> I changed error detection, the error is raised when doing the transition
> to it immediately, and error information are now provided immediately
> with the initial example xmllint --noout --schema errRep1.xsd errRep1_0.xml
> we now get the following error informations:
>
> Breakpoint 1, testerr (exec=0x98c8520) at xmlregexp.c:3302
> 3302        int nb = 5;
> (gdb) n
> 3304        xmlRegExecErrInfo(exec, &string, &nb, &values[0], &terminal);
> (gdb)
> 3305    }
> (gdb) p string
> $1 = (const xmlChar *) 0x98c9380 "x|http://FOO";
> (gdb) p nb
> $2 = 3
> (gdb) p values[0]
> $3 = (const xmlChar *) 0x98c6bd8 "b|http://FOO";
> (gdb) p values[1]
> $4 = (const xmlChar *) 0x98c6c48 "*|*"
> (gdb) p values[2]
> $5 = (const xmlChar *) 0x98c7038 "c|http://FOO";
> (gdb) p terminal
> $6 = 0
> (gdb)
>
>    Note that since the transition though *|http://FOO goes to a sink
> state it is not listed, but alternatively it could be still provided and
> marked as such, for example by getting a nbneg int* parameter. All
> negative transitions (i.e. going to a sink state) could then be added
> after the nb ones in the values[] tab, and in that specific case it would
> one would get:
>
>    nb = 3
>    nbneg = 1
>    values[0] = "b|http://FOO";
>    values[1] = "*|*"
>    values[2] = "c|http://FOO";
>    values[3] = "*|http://FOO";
>    
>   I think such an API would allow complete analysis and report without
> needing to provide extra implementation details or new strings in the 
> regexp format.

Cool, adding a nbneg sounds simpler than anything else.

But there is still a problem: the negated namespace wildcard is build
using two transitions: "*|http://FOO"; leading to the sink state, and
"*|*" passing all other elements through. The "*|*" would not be
distinguishable from a <any namespace="##any"/> wildcard. Maby the
build of the automaton can be changed somehow to avoid this. Hmm,
is it possible to extend the sink state detection to handle this,
i.e. to surpress the report of such a "only-way-out-of-sink" transition?

Thanks,

Kasimier