Re: [Schematron-love-in] Re: Cocoon Form binding and validation

[Ivelin Ivanov <iv...@iname.com>]

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: kk@kohsuke.org


_______________________________________________
Schematron-love-in mailing list
Schematron-love-in@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/schematron-love-in




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org