Re: [xml] Schema validity failure for valid document

[Daniel Veillard <veillard redhat com>]

On Tue, Jan 11, 2005 at 12:14:19PM +0100, Kasimier Buchcik wrote:
> Hi,
>
> Daniel Veillard wrote:
> > > What about the following:
> > > 1. xmlRegExecErrInfo would return an array of automaton transition
> > > indices (well, if the transitions are accessible through an index).
> > > 2. We could then iterate through all the given transitions and extract
> > >  the info using accessor functions like:
> > >  const xmlChar * xmlRegExecGetValue(int transitionId)
> > >  void * xmlRegExecGetData(int transitionId)
> >
> >
> >  Too complex. Depending on the compilation you may address transitions 
> > with integers or with pointers. I don't think exposing that deep a level
>
> I don't agree that it's too complex and exposing. If the atoms holding
> the information would be always accessible through integer indices in
> xmlregexp.c (and I think any struct can be put in an array and be given
> an index), accessor functions would be the most encapsulating and
> extensible access to those informations I can think of. Plus, access of
> information items through integer indices is a highly abstract thingy.
> So not exposing at all IMHO.

  I think it exposes too much of the implementation that it would prevent
different implementation stategies. For example if I wanted to integrate
RNG derivation based kind of validation stategies, then you don't have
transitions in a given state but an expression of the remaining formal
automata accepted at that point. This is crossing the interface exposing
the implementation stategy, and I prefer to avoid this. Extracting potential
accepted tokens does not expose the implementation stategy.

> > 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.

  Do you want an integer or a char pointer ?

> > sounds way simpler to implement and use. When building those "dead" 
> > transition
> > you know what they represent and what to report if transiting though them.
>
> In this case yes, the negated namespace wildcard is the only one with a
> dead-end; so it's distinguishable.

  Okay, but dead-end state are unlikely to be generated by normal regexp
process but since we expose automata APIs I prefer a more generic apparoach.
It also sounds the right solution from a formal point of view, it should
still work if we change the automata generated for whatever reason.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/