[EMAIL PROTECTED] wrote:
<snip/>
> > 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.
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?
> > 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 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.
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.
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.
I think I could help with this.
Jan Dvorak
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
