> > > a) the full path to the node that cause the error
> >
> > You can easily do it by yourself. We don't want other users who don't
> > want such list to suffer from the performance impact of computing it.
You mean by wrapping the handler?
> How about having a feature, false by default, to switch this on?
> This could be a useful extension, IMO.
> (See my other today's posting for my motivation.)
> What's the Xerces policy in cases like this?
I'd like to second that!
> > > b) not just a text message but an object (some kind of constraint or
> > > facet object) that makes machine based processing based
> > > on the validation result possible.
> > > AFAICS the current information is only useful if you want to pass
> > > it directly to a user. I'd need to parse it to get the desired
> > > information. (but that would ugly as hell...)
> >
> > How do you think such object would look like? There are so many different
> > kinds of errors. I don't think it's possible to capture all parameters
> > ('2', '50' in you example) of all those errors in one object. One thing
no... that wasn't the idea...
> > you can get out of the error message is the error code, which tells you
> > which constraint was violated. This doesn't solve your problem, but it
> > might be helpful.
Let's say we define a constraint interface like this:
interface Constraint {
public boolean isSatisfiedWith(Object value, Context context);
public String getErrorMessage(Locale locale);
}
then there could be a
public class RegexprConstraint implements Contraint {
public boolean isSatisfiedWith(Object value, Context context) {}
public String getErrorMessage(Locale locale) {}
public String getExpression();
}
and so on... a list of *failed* constraint (facets or whatever interface there
might be in xerces) will be the result of a validation - not just a boolean
with spitting out some errors messages...
see my direction?
> We can see an array of parameters of the error call, but the roles of these
> parameters are unclear: they are only given by the message string.
>
> Moreover, the parameters of the reportError are objects; they come from
> somewhere and they should be able to tell this location.
> In Torsten's example, the '2' comes from the instance document (from a
> particular location therein, in fact) while the '50' comes from the Schema
> (from a particular type definition used with a particular element/attribute
> declaration). It would be nice if we had this info along with the string.
I totally aggree
> To me, having separate classes for different error types, or perhaps groups
> of error types, looks like sound OO design. Then we could apply the Visitor
> design pattern. Formatting a message by substituting different parameters
> is one action we want to support, but there may be other actions (as
> Torsten suggests) or we may want to process the errors before we format
> them (as I suggest in my other posting). That's done much easier with
> objects than with an error code and an array of parameters.
exactly! ....see the above interface
And it would also be great if one could as the schema for the constraints for
a certain xpath. Something like
Constraint[] = schema.getConstraints("/root/foo");
As a summary: I think (as much as I can say) xerces is currently too much of a
blackbox in terms of validation. It would be great to have some API to get a
bit more then just valid/invalid... (I don't take text error message into
account - they are for human eyes only)
> I think I could help with this.
I'd love to help, too! Although I not very familiar with the xerces codebase
yet...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
