Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 92541 invoked by uid 500); 17 Mar 2002 15:43:53 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 92526 invoked from network); 17 Mar 2002 15:43:53 -0000 Message-ID: <00e901c1cdcb$a3782620$0c91fea9@galina> Reply-To: "Ivelin Ivanov" From: "Ivelin Ivanov" To: References: Subject: Re: Dynamic Schematron validation works! Date: Sun, 17 Mar 2002 09:51:44 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ----- Original Message ----- From: "Torsten Curdt" To: ; "Ivelin Ivanov" 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: > > > > > > > > > > ... go back to the same page > > > > ... 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