----- Original Message -----
From: "Torsten Curdt" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Ivelin Ivanov" <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
