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

Re: [xml] Schema validity failure for valid document



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/



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