Cart
[Home] [By Thread] [By Date] [Recent Entries]
Oliver Becker wrote: > > Hi Rick, > Would it be reasonable to change Schematron into a real open source > project supported by several contributors (hosted on sourceforge, for > example)? Yes. The cunning plan is to make Schematron more *) innovator/implementor friendly -- I have been thinking about Sourceforge and improving the API *) brandable -- corporate developers will not be keen to integrate Schematron into their products unless it has some perceived usefulness by buyers: to help this we are looking at some trademarking and branding issues--but to protect and promote only--it will still be free and open; *) integratable into XML Schemas and RDF -- initially this will be just a preprocessor for embedded Schematron schemas in XML Schemas: when used with a type-aware DOM or type-aware XPath, Schematron automatically inherits XML Schemas typing information for free! > Unfortunately I don't have any experience with that. It is a goo time to start. I will try to get it organized for the first week of September, after I come back from my holiday in Australia. > Schematron is very fine - but sometimes limited. So I add things myself > and write proprietary Schematron preprocessors (using an extended > Schematron language). Other users might do similary things ... I wonder if there is a way to ramp up the new architecture to support other elements/attributes in different namespaces as extensions better. In other words, can we make the new architecture itself dynamically extensible. What I am thinking of is that if you add extensions in a new namespace, we provide a mechanism to register the default skeleton handlers for it as well. > I think a little effort to concentrate the Schematron activities makes > a lot of sense. It is a wide-open field. There are many interesting and useful directions available. The ones I am interested in include: The theoretical issues about using a schematron schema as a system of constraints (i.e. to allow checking of rule clashes and for building smart editors) have not been worked on (I think there is a University in US doing this for XML Schemas). The WAI people have asked about moving Schematron to do repair as well as diagnosis: how? Do we need a generic API for error-reporting/diagnostics? The current line-based format (i.e., the EMACS format used by XED and schematron-message) is nice, but the resulting data is not rich: if we had a generic API (e.g. Exception Reporting Routines--ERR), then developers could plug different schema languages and implementations in: SAX or DOM in, ERR out. Paul Prescod and Dan Connolly have been building intersting applications on top of XPath based assertion systems: can these be folded into Schematron? How to declare that particular XSL extensions are being used. XSL has the hooks we need for this already. One area that I am deliberately not persuing is to get Schematron to parse or simulate content models in any detail: it would be possible multiple nested rules, but not very efficient. But I think grammar-based schemas are to a certain extent a convenient hack rather than embodying good software engineering or modeling principles, and I am not interested in getting into any competition with XML Schemas/XDR or RELAX/DSD or SOX or DTDs. If Schematron has a future, I think it has to have a distinct character and niche to other schema languages. Rick Jelliffe
|
