better validation of Schematron schema
Hi, My request here does not have to do with validating an XML document against a Schematron schema, but rather, finding out whether Schematron schema itself is valid. I'm pleased with Oxygen's support for Schematron, including ISO Schematron. Oxygen really has excellent coverage of XML-related tools. However I have the following enhancement request. When I'm editing a schema foo.sch in oXygen, I can press Ctrl+Shift+V and it does something, and says "Document is valid." I guess it's validating the schema against an RNG schema for Schematron? I don't know. What I do know is that its validation is not as complete as the validation for XSLT stylesheets. It helpfully validates the presence of elements and attributes that are dis/allowed in Schematron (old and ISO versions); but it does not validate the XPath in test expressions. Just now I had an assert whose test attribute's value was not well-formed XPath: <sch:assert test="../../row1/thing[@id = current()/transform[@type = 'From']/target/@id"> Note that I'm missing a final square-bracket in the test expression. Yet Oxygen tells me the Schematron schema is valid. It was only when I tried to *use* the Schematron schema that it told me about the missing ']'. And at this point it's quite a bit harder to debug, because often you're using a manually-constructed pipeline where you have an XSLT transforming your Schematron schema to another XSLT, and then the latter is used to validate your XML document. So you have to sort through several layers to figure out where the problem is. So my request is for stronger validation for Schematron schemas. I'm not sure of the best way to accomplish this... Maybe Oxygen could go ahead and transform the schema to an XSLT using e.g. iso_svrl.xsl and iso_schematron_skeleton.xsl (in the case of ISO Schematron); then validate the result as an XSLT stylesheet. This should take care of the above problem, malformed XPath expressions. It may not be straightforward to map any errors back to a particular point in the original schema, but at least we'd know whether the schema was valid or not, and we'd be better off than we are now, catching errors while editing the schema instead of when using the schema. Thanks for your consideration, Lars
Hi, I second Lars' request for generally tighter validation of Schematron, especially when it comes to XPaths. This would really help tighten the development cycle. It could be that converting the Schematron into XSLT for validation isn't necessary, if the editor could be aware of Schematron in a way similar to its awareness of XSLT ... in particular, that Schematron rule/@context and (assert|report)/@test attributes need to be XPath. I suppose this is complicated by the fact that they don't ... a Schematron might have any of a number of queryBinding values at the top level. But presumably it makes sense for oXygen to validate only the query languages it actually supports. Could oXygen be smart enought to check for XSLT 1.0 XPath when queryBinding="xslt" and XSLT 2.0 XPath when queryBinding="xslt2"? To be really complete, it would also have to traverse Schematron include elements and even xsl:import or xsl:include elements (for those of us who mix XSLT in, and maintain XSLT functions in other modules). Cheers, Wendell ====================================================================== Wendell Piez mailto:wapiez@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
Dear Lars, Thanks for your feedback! You identified exactly the problem, tracing back the errors to the original schema. Our implementation is based on skeleton, simplified a little as we know the XSLT engine that we use and I also added support for includes and abstract schemas - that means there are a couple of XSLT stylesheets until we get the XSLT from Schematron. I will see what we can do about that, I agree that better validation for Schematron will be a nice thing to have in oXygen. Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 5/26/10 7:35 PM, Lars Huttar wrote:
Hi, My request here does not have to do with validating an XML document against a Schematron schema, but rather, finding out whether Schematron schema itself is valid.
I'm pleased with Oxygen's support for Schematron, including ISO Schematron. Oxygen really has excellent coverage of XML-related tools. However I have the following enhancement request.
When I'm editing a schema foo.sch in oXygen, I can press Ctrl+Shift+V and it does something, and says "Document is valid." I guess it's validating the schema against an RNG schema for Schematron? I don't know. What I do know is that its validation is not as complete as the validation for XSLT stylesheets. It helpfully validates the presence of elements and attributes that are dis/allowed in Schematron (old and ISO versions); but it does not validate the XPath in test expressions. Just now I had an assert whose test attribute's value was not well-formed XPath: <sch:assert test="../../row1/thing[@id = current()/transform[@type = 'From']/target/@id"> Note that I'm missing a final square-bracket in the test expression. Yet Oxygen tells me the Schematron schema is valid.
It was only when I tried to *use* the Schematron schema that it told me about the missing ']'. And at this point it's quite a bit harder to debug, because often you're using a manually-constructed pipeline where you have an XSLT transforming your Schematron schema to another XSLT, and then the latter is used to validate your XML document. So you have to sort through several layers to figure out where the problem is.
So my request is for stronger validation for Schematron schemas. I'm not sure of the best way to accomplish this... Maybe Oxygen could go ahead and transform the schema to an XSLT using e.g. iso_svrl.xsl and iso_schematron_skeleton.xsl (in the case of ISO Schematron); then validate the result as an XSLT stylesheet. This should take care of the above problem, malformed XPath expressions. It may not be straightforward to map any errors back to a particular point in the original schema, but at least we'd know whether the schema was valid or not, and we'd be better off than we are now, catching errors while editing the schema instead of when using the schema.
Thanks for your consideration, Lars
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
Hello, Just "seconding" my own vote here for improved validation of Schematron schemas in Oxygen. Again today I ran into the problem where Oxygen says the schema is valid, but in fact the XPath had a problem. In this case, there were two problems: 1) an XPath expression used a namespace prefix which was included in an xmlns: namespace declaration, but was not declared using <sch:ns>: <sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron" xmlns:svrl="http://purl.oclc.org/dsdl/svrl"> ... <sch:assert test="$SVRL-results//svrl:failed-assert"> 2) a rule/@context expression used a variable, which is not allowed (at least the generated stylesheet is not valid XSLT): <sch:rule context="$original-schema/sch:assert"> As before, in both cases, the problems were hard to debug because they were reported at runtime, after the Schematron schema had been transformed into transient XSLT. Strong validation of the schema, catching them at schema-editing time, would have made things easier to diagnose and fix. I don't suppose there's a Schematron implementation out there that works without the XSLT-generation step, and reports validation errors in direct reference to the Schematron schema? E.g. Probatron4j (I haven't tried it)? Thanks... Lars On 5/27/2010 3:58 AM, George Cristian Bina wrote:
Dear Lars,
Thanks for your feedback! You identified exactly the problem, tracing back the errors to the original schema. Our implementation is based on skeleton, simplified a little as we know the XSLT engine that we use and I also added support for includes and abstract schemas - that means there are a couple of XSLT stylesheets until we get the XSLT from Schematron. I will see what we can do about that, I agree that better validation for Schematron will be a nice thing to have in oXygen.
Best Regards, George
I'll "third" that vote. As I'm sure you also know, George, when there is a "failure to compile Schematron" error when validating a document with an associated Schematron, the reported line numbers for the location of the offending statement in the Schematron are typically off by some (variable) number of lines. I imagine this relates to the stylesheet pipeline probably transforming the Schematron first into some canonical representation with potentially different number of lines. John On Jun 16, 2010, at 3:21 PM, Lars Huttar wrote:
Hello, Just "seconding" my own vote here for improved validation of Schematron schemas in Oxygen. Again today I ran into the problem where Oxygen says the schema is valid, but in fact the XPath had a problem. In this case, there were two problems:
1) an XPath expression used a namespace prefix which was included in an xmlns: namespace declaration, but was not declared using <sch:ns>: <sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron" xmlns:svrl="http://purl.oclc.org/dsdl/svrl"> ... <sch:assert test="$SVRL-results//svrl:failed-assert">
2) a rule/@context expression used a variable, which is not allowed (at least the generated stylesheet is not valid XSLT): <sch:rule context="$original-schema/sch:assert">
As before, in both cases, the problems were hard to debug because they were reported at runtime, after the Schematron schema had been transformed into transient XSLT. Strong validation of the schema, catching them at schema-editing time, would have made things easier to diagnose and fix. I don't suppose there's a Schematron implementation out there that works without the XSLT-generation step, and reports validation errors in direct reference to the Schematron schema? E.g. Probatron4j (I haven't tried it)?
Thanks... Lars
On 5/27/2010 3:58 AM, George Cristian Bina wrote:
Dear Lars,
Thanks for your feedback! You identified exactly the problem, tracing back the errors to the original schema. Our implementation is based on skeleton, simplified a little as we know the XSLT engine that we use and I also added support for includes and abstract schemas - that means there are a couple of XSLT stylesheets until we get the XSLT from Schematron. I will see what we can do about that, I agree that better validation for Schematron will be a nice thing to have in oXygen.
Best Regards, George
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
Hey George et al., I just posted on the web forum a question about getting SVRL out of a Schematron validation, instead of the oxygen native view. On second thought, I guess this thread is a better place to post the question. I'm wondering whether I could get the SVRL output instead of/in addition to the native error pane display. When I look at Rick J's latest version of the skeleton.xsl pipeline (http://www.schematron.com/implementation.html and in particular the link on that page to iso-schematron-xslt2.zip), I see that he's basically defaulting to SVRL output in any case. As far as I can tell, in oxygen 11.2, there is no option currently to save/view the native SVRL output instead of/in addition to the built-in validation error pane display. This would be very desirable (for me, anyway) in 11.3. (I'm trying to convince a client to put a Schematron validation step in their process pipeline, and they want to know, as well they should, "what's the validation output gonna look like?". The answer is SVRL, but I want to be able to show it to them.) I could just set up a separate transformation scenario using the download from Rick J, but it would be really nice if you could make it a native option in oxygen -- unless it's already there and I'm just like an idiot completely missing it. John On Jun 16, 2010, at 4:06 PM, John Madden wrote:
I'll "third" that vote.
As I'm sure you also know, George, when there is a "failure to compile Schematron" error when validating a document with an associated Schematron, the reported line numbers for the location of the offending statement in the Schematron are typically off by some (variable) number of lines. I imagine this relates to the stylesheet pipeline probably transforming the Schematron first into some canonical representation with potentially different number of lines.
John
On Jun 16, 2010, at 3:21 PM, Lars Huttar wrote:
Hello, Just "seconding" my own vote here for improved validation of Schematron schemas in Oxygen. Again today I ran into the problem where Oxygen says the schema is valid, but in fact the XPath had a problem. In this case, there were two problems:
1) an XPath expression used a namespace prefix which was included in an xmlns: namespace declaration, but was not declared using <sch:ns>: <sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron" xmlns:svrl="http://purl.oclc.org/dsdl/svrl"> ... <sch:assert test="$SVRL-results//svrl:failed-assert">
2) a rule/@context expression used a variable, which is not allowed (at least the generated stylesheet is not valid XSLT): <sch:rule context="$original-schema/sch:assert">
As before, in both cases, the problems were hard to debug because they were reported at runtime, after the Schematron schema had been transformed into transient XSLT. Strong validation of the schema, catching them at schema-editing time, would have made things easier to diagnose and fix. I don't suppose there's a Schematron implementation out there that works without the XSLT-generation step, and reports validation errors in direct reference to the Schematron schema? E.g. Probatron4j (I haven't tried it)?
Thanks... Lars
On 5/27/2010 3:58 AM, George Cristian Bina wrote:
Dear Lars,
Thanks for your feedback! You identified exactly the problem, tracing back the errors to the original schema. Our implementation is based on skeleton, simplified a little as we know the XSLT engine that we use and I also added support for includes and abstract schemas - that means there are a couple of XSLT stylesheets until we get the XSLT from Schematron. I will see what we can do about that, I agree that better validation for Schematron will be a nice thing to have in oXygen.
Best Regards, George
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
participants (4)
-
George Cristian Bina -
John Madden -
Lars Huttar -
Wendell Piez