OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: Schematron (was Re: Remember to RELAX)

[ Lists Home | Date Index | Thread Index ]
  • From: Rick JELLIFFE <ricko@geotempo.com>
  • To: xml-dev@lists.xml.org
  • 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
> 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
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.

Rick Jelliffe


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS