cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@iname.com>
Subject Re: Dynamic Schematron validation works!
Date Sun, 17 Mar 2002 15:51:44 GMT

----- Original Message -----
From: "Torsten Curdt" <tcurdt@dff.st>
To: <cocoon-dev@xml.apache.org>; "Ivelin Ivanov" <ivelin@sbcglobal.net>
Sent: Sunday, March 17, 2002 9:11 AM
Subject: Re: Dynamic Schematron validation works!


> > > 2) AFAIU validation happens inside the XSLT transformer. IMHO this
should
> > >    happen inside an action. Otherwise we have to choose what page to
show
> > >    from the XML *content*. Only way I see do this is to create another
> > >    transformer for this. But still you are not able to react on the
> > >    validation result inside the sitemap... Or am I missing here
something?
> > >    (Could a transformer set a request attribute that can become
available
> > >    in the sitemap?)
> >
> > I've come up with 2 possible solutions to this problem so far.
> > (It seems that you came to the same yourself. )
> >
> > 1) I think we can do a specialized "Validation" transformer, which
extends
> > from XSLT transformer, but also sticks in the sitemap a
"validationResult"
> > attribute, which a subsequent selector can use. The idea seems feasible
> > based on the behaviour of the WritingDomTransformer which sticks in the
> > sitemap a DOM object representing the SAX stream.
>
> this is the only way I see for this approach. but Ivelin: isn't there a
> way of using schematron more in a java way? as long as you want schematron
> only to display some errors fine. But ussually I check my business
> objects again before I save them inside an action. Something like:
>
>   save-action() {
>     if (bo comforms to XSD) {
>       save to whatever
>     }
>     else {
>       error: bo does not conform to XSD
>     }
>   }
>
> How would you do this with schematron inside an action. I'd be glad if we
> could find a way to do this with schemtron, too.

Before I answer, I'd make a note that I am not aware of a XSD validator
which can go directly against a JavaBean.
So I assume that this line
>     if (bo comforms to XSD) {
actuall assumes an implicit transition from BO to XMLSource to XSD
validation.

If we want to stick to the XSLT implementation of Schematron, then

XMLSource myBOasXML = Castor.marshall (bo) ;

  save-action() {
    // XSD validation
    if (myBOasXML comforms to XSD) {
      // Schematron validation
      XMLSource schemtraonResultAsXML = XSLT.process( myBO,
mySchematronStylesheet )
      CastorOrJAXB.unmarshall ( schemtraonResultAsXML,
schematronResultJavaBean );
       if ( schematronResultJavaBean.errors > 0 )
         {
         DING, ERROR, display errors and diagnostics
         }
       else
          save to whatever
    }
    else {
      error: bo does not conform to XSD
    }
  }

Maybe it's preferable though to use the Java implementation of Schematron:
http://www.informatik.hu-berlin.de/~obecker/SchematronAPI/

It works fine against DOM. It shouldn't be too hard to extend it to work
directly with BOs by replacing the XPath calls to a DOM with JXPath calls to
the BO.

>
> > 2) How about a XPath selector, whose when attribute will be a valid
XPath
> > test expression executed against the SAX stream?
> > then you can possible do something like:
> >
> > <transformer src="validating-schematron-report.xsl">
> > <selector type="xpath">
> >   <selector when="/validatingResult/pattern">
> >     ... go back to the same page
> >   <selector otherwise>
> >     ... move on with life
> >
> >
> > So which one of the two (if any) is better ?
>
> AFAIK this is not possible without creating a DOM.... we have had a
> discussion on this topic lately...

What if we implement only the subset of XPath which satisfies 90% of the
needs and can work with a SAX stream.
Many times the test would be like:
1) Does element A exist, or
2) Does element A have value b, or
3) Does element A appear n times, or
4) similar tests against attributes

All of the above can work with SAX stream without the need to remember the
whole document.



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


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


Mime
View raw message