[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [xml] Schema validity failure for valid document
- From: Daniel Veillard <veillard redhat com>
- To: Kasimier Buchcik <kbuchcik 4commerce de>
- Cc: xml gnome org
- Subject: Re: [xml] Schema validity failure for valid document
- Date: Tue, 11 Jan 2005 07:38:49 -0500
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]