Lists Home |
Date Index |
- From: Rick JELLIFFE <firstname.lastname@example.org>
- To: email@example.com
- Date: Wed, 02 Aug 2000 20:07:37 +0800
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
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
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
> 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
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.