xml-dev - Re: Schematron (was Re: Remember to RELAX)

[Rick JELLIFFE <ricko@geotempo.com>]

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