Koshuke,
<snip/> >> If you have experience with JARV, can you scetch how the new/fast Schematron >> validation can be wrapped in JARV without loss of efficiency? >I'm not subscribing to the cocoon-dev list, so I don't quite follow the >context. But I'm happy to see if I can write a JARV wrapper around >Schematron implementation. Where can I find that "Torsten's API"? http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/scratchpad/webapp/mount/pr ecept/README?rev=1.1&content-type=text/vnd.viewcvs-markup We're still working to polish it up, but you can gain enough information to join the discussion. >As for performance, if you want to validate SAX events with Schematron, you have to expect the overhead of building DOM, as Schematron needs access to the entire DOM. Also, for this reason, it is difficult to achieve fail-fast validation with Schematron. So if you are validating SAX events, it can be the case that your ContentHandler will see some data, which then be detected to be an error at some later time. >> 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? >This is the first time I've heard about "domain object validation." Would you elaborate on this more? Ok, let me try: Consider this example (extract from Konstantin's XForms sample): <customer id="102038" type="individual"> <firstname>John</firstname> <lastname>Lennon</lastname> <citizenship>RU</citizenship> <has-car>false</has-car> <car-info> <issue-year>1999</issue-year> <model>Volkswagen Passat</model> </car-info> </customer> This document describes a Customer domain object. class Customer { Sttring firstName; ... etc. get/setCarInfo } class CarInfo ... The Customer domain object would be typicly engaged in the following areas of a business application: = UI. - CRUD (create, read, update, delete) a customer. Requires interaction with client app, which could be a web browser w/ HTML forms, applet, desktop java or native app. The data can be delivered via HTTP POST, RMI, CORBA or other. As data is received it is unmarshalled to a domain object, verified and processed. Validation is usually performed in stages depending on the UI context and client capabilities. = Business Domain. - Customer CRUD as a side effect of a business process: car purchase, car trade in, car repair, etc. Data is available as part of the state of a domain object. Validation may be partial or complete depending on the requirements. = Persistance - Customer CRUD in a database. Requres interaction with a persistance store. When read, the data is usually available as a flat result set (RDBMS are still dominant) which is used to populate a domain object, verified and handed to the application for further processing. Before written, the data is available as part of the state of the domain object. Its verified and then persisted. Validation is usually complete in both directions. = Web Services - Customer CRUD through RPC or messaging. Requres interaction with remote applications through a standard Web Services protocol. Data is usually transmitted as XML documents which are unmarshalled to Java domain objects. Validation is usually complete in both directions. In all of the scenarios above the business rules defining a valid Customer document/object or its parts are the same. Therefore I would like to keep them in a single schema document which is distributed together with the domain object definition. For example I would like to avoid coding the UI validation separately from the persistance validation. One may argue that this is possible by writing all the rules in a CustomerValidator class which is used throughout the application. That is true. However when the Web Services case is introduced, the peers may not be written in Java (.NET will probably not vaporise), and even if they are they may not be willing to use my code for various reasons. Since we have to agree on the document format to be able to conduct web service transactions though, it'll be natural to agree on a XML validating schema. With the Schematron Java API, I targeted exactly the goals above. It is currently useful by itself, but it would be much more powerful as a part of a generic validation API. I hope I made my point clear without being too verbose. <snip> >Reporting meaningful error messages is a tricky business. I don't think >JARV can be extended to nicely support this kind of needs, while >maintaining schema neutrality and implementation independence. How about a ValidationErrorHandler which assembles a set of ValidationErrors (which in turn extend SAXParserError). A ValidationError has at least information about the element location and a message. Also the Verifier interface that allows not only DOM documents but also plain Objects (which could be introspected). As I mentioned JXPath acts on both Objects and DOM nodes as well as mixed content, objects with Dom nodes as attributes. It dynamicly detects and traverses the tree. http://cvs.apache.org/viewcvs/jakarta-commons/jxpath/ Finally Verifier.verify( object ) that returns Set or Map instead of boolean. Set of ValidationErrors or Map of (element location , set of ValidationErrors for the element) elements. > 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? > Maybe I'm missing your point, but how about visiting JavaBeans and generating SAX events? You can direct those events to JARV and then JARV can report any validation error. You'll then immediately know which Java object causes the trouble. This works just fine. Would you consider to change the validate() return type as mentioned above, so that people will not need to implement custom error handlers most of the time. Only the Validator implementer will need to provide a ValidationErrorHandler . <snip/> >> OK. So if you want to validate a set of nodes (a phase) you'll need to rerun >> validate on each one? >What do you mean by "a set of nodes"? Is it a set in mathematical sense (an orderless collection of things)? Or is it a sequence in mathematical sense (an ordered collection of things)? I meant "an orderless collection of things". >If former, then Yes, you'll need to call the verify method for each Node. And since a set is orderless, you can't do better than that. Ok. Then I think I understand how Schematron Validator for JARV should be implemented. I can do that quite easily, but it would be of practical use if we can deliver the set of errors at the end of the validation. Which goes back to my suggestion above. Thanks for reaching this line ;)) Ivelin >If you meant latter, then calling the verify method for each element may not give you what you want to achieve, as you might want to check not only the descendants but the sequence itself. regards, ---------------------- Kohsuke Kawaguchi E-Mail: [EMAIL PROTECTED] _______________________________________________ Schematron-love-in mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/schematron-love-in --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
