Re: [lxml-dev] [Bug 488222] Feature request: add better schematron support to lxml

Committed to trunk: https://codespeak.net/viewvc/?view=rev&revision=71090 This simply exposes the skeleton xslt steps and the validation result xpath as class attributes. I consider the iso-schematron works pretty much finished for now... Holger -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Hi,
Nevertheless, I've been thinking about this a bit more: What about generalising the approach to an "XSLValidator" approach that basically - uses a (series of) "validating" XSLT tranformation(s) - to create an output document (an output "report") - based on which actual input validity gets determined by an XPath expression. The isoschematron Schematron class would then be some specialization of this. Not sure how to support the separate steps with their own parameters to create the "validating XSLT" from the input schema, though. Maybe we'd need to separate this into some worker "XSLProvider" class. Holger -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

jholg@gmx.de, 03.03.2010 09:15:
While this sounds interesting in general, I'm not sure if there is a) a use case for this (Schematron is likely as good as you can get anyway), and b) enough to generalise. The above things aren't hard to implement (XPath is two lines, XSLT maybe three), so before we have a second schema language / use case that shows what the truely overlapping parts are, I don't see how to extract a good abstraction from this. That doesn't mean I'm against such an idea. Wouldn't be the first time that new abstractions lead to new ideas. I'm just suggesting that it's the kind of idea that needs an implementation with examples before evaluating the design. Stefan

Hi,
Nevertheless, I've been thinking about this a bit more: What about generalising the approach to an "XSLValidator" approach that basically - uses a (series of) "validating" XSLT tranformation(s) - to create an output document (an output "report") - based on which actual input validity gets determined by an XPath expression. The isoschematron Schematron class would then be some specialization of this. Not sure how to support the separate steps with their own parameters to create the "validating XSLT" from the input schema, though. Maybe we'd need to separate this into some worker "XSLProvider" class. Holger -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

jholg@gmx.de, 03.03.2010 09:15:
While this sounds interesting in general, I'm not sure if there is a) a use case for this (Schematron is likely as good as you can get anyway), and b) enough to generalise. The above things aren't hard to implement (XPath is two lines, XSLT maybe three), so before we have a second schema language / use case that shows what the truely overlapping parts are, I don't see how to extract a good abstraction from this. That doesn't mean I'm against such an idea. Wouldn't be the first time that new abstractions lead to new ideas. I'm just suggesting that it's the kind of idea that needs an implementation with examples before evaluating the design. Stefan
participants (2)
-
jholg@gmx.de
-
Stefan Behnel