Mats, Thanks for the response, hope Koshuke can help with the open questions.
... see below ... ----- Original Message ----- From: "Mats Norén" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Ivelin Ivanov" <[EMAIL PROTECTED]> Sent: Thursday, March 28, 2002 5:16 AM Subject: Re: Cocoon Form binding and validation [was: RE: SchemoX forms] > The SaxErrorHandler can, to the best of my knowledge, NOT provide you with > the XPath location of the bad element, > a quick workaround is to implement a tag tracking Stack in the errorhandler. > I build the XPath-expression when the events flow in and when an error occur > in an element I peek at the stack and use that as the location. > In an conversation with Kohsuke Kawaguchi, the developer, he proposed the > following solution: That is a possible solution. Developers which are validating DOM and JavaBeans would be really interested in a set of XPath locators with corresponding error messages. So I guess JARV is the validator skeleton which can be wrapped around Torsten's API and used for its broad schema support. If you have experience with JARV, can you scetch how the new/fast Schematron validation can be wrapped in JARV without loss of efficiency? > <paste> > Umm, I'm not sure if I want to add such a specialized capability into > the generic verifier implementation. > > It seems like the same goal can be achieved by using a SAX XMLFilter. > Let's say there is an XMLFilter that tracks XPath. You can set up the > pipeline as follows > > parser --> XPathTracker --> VerifierFilter --> YourHandler > > XPathTracker and VerifierFilter don't know anything about each other. > XPathTracker will update XPath information before it passes an event to > the next handler (in this case that's VerifierFilter.) > > Once an error is reported by VerifierFilter, the error handler can ask > XPathTracker about the current XPath, it can then process > ValidityViolation with XPath. > > XPathTracker only need to track element-level XPath. I can update MSV to > report more information about attributes (i.e., which attribute went > wrong? was it because of the bad value, or the attribute is undeclared?) Would be very helpful. I guess the layer above JARV will have to convert these errors into human readable messages. Is this always possible? Can MSV report if the name attribute was NULL or it was bigger than 30 characters? Both these constraints can be expressed with XSD, so they can probably be reported as well. I guess the issue how to plug that information in a standard API which will work well enough for different schemas. Have you considered support for Schematron and other rule/semantics based schemas or just grammar based schamas ? The nice thing about Schematron for user input validation is that it can report a human readable message back. I have also like to get some response to the question of JavaBeans validation. Domain object validation through schemas is useful, how does it work with JARV? To restate my question again: The API is designed to work with DOM. So when I would like to validate domain objects as JavaBeans, I'll need to first convert the JavaBean to DOM with Castor or similar, before I can validate it? Is there a more efficient solution, similar to the JXPath based Schematron implementation, which only travers to the JBean/DOM nodes which need to be validated? > </paste> > > > Also, how would you use JARV to implement partial document validation? > > For example if you want to validate the user/car-info/model element, but > not > > necessary the whole user element. > > With MSV you can verify a single DOM Node and not the entire document. > verifier.verify(Node node) should work as well as verifier.verify(Element > element) OK. So if you want to validate a set of nodes (a phase) you'll need to rerun validate on each one? > > BTW, what exactly is the MSV license. It seemed like its was open source, > > but it wasn't very clear to me. Is it compatible with Apache's? > > Not sure about that. The best thing to do is to ask the developer Kohsuke > Kawaguchi. > [EMAIL PROTECTED] > > > > > Cheers, > > > > Ivelin > Regards, > > Mats > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
