Altova Mailing List Archives

Re: XML Schemas: Best Practices

From: Francis Norton <francis@-------.--->
To: Eddie Robertsson <eddie@-------.---.-->
Date: 2/28/2001 6:17:00 AM
Eddie Robertsson wrote:
> I've been experimenting with validation that can't be done by XML Schemas
> and the option I choose to use was Schematron. I don't have any particular
> reason for my choice more than that I knew Schematron was capable of
> validating problems like in your example above. What surprised me was how
> easy it was to learn how to use Schematron (if you have knowledge of XPath
> and XSLT). Since Schematron use (maybe doesn't have to?) XSLT as the
> validation engine much of what you can do with writing your own stylesheet
> (option 3 below) can also be done using Schematron. Maybe if your an expert
> using XSLT you don't mind writing your own validation stylesheets but I
> found Schematron much easier to use. Yes, you have to learn how to use
> Schematron but you learn the basics in a couple of hours.
Yes, I'm a schematron fan - I'm always astonished that something so easy
to master can be so unreasonably effective. I also like the idea that
you can put your schematron schema - assembled as you say from inside
the xsd:appinfo elements - through different schematron compilers (all
written in XSLT) to generate different schema validators, the difference
being that one in an IDE might generate its results as say HTML, another
in a text editor might output text, and a third in an application might
generate XML. 

> The way I solved this was to write a very simple XSLT stylesheet that simply
> finds all the element from the Schematron namespace within the <xsd:appinfo>
> element in my XSD Schema. The stylesheet concatenated all this Schematron
> information to a Schematron schema which could be used for validating the
> things XSD could not validate (NOTE: this idea came from Rick Jelliffe [1]).
> By using the command line version of XSV, Saxon and a simple batch file I
> could do all the validation in one step.
You're ahead of me here - I haven't yet implemented this. Would you be
inclined to post a minimum-but-complete example? With my FAQ hat [1] on
this might be a good answer to both "what's xsd:appinfo for?" and "how
do I do co-constraint validation in the current version of XML Schema?"

> >
> > {3} Recall that this option says: "write a stylesheet to express the
> > additional constraints".  I like this approach for the following
> > reasons:
> >
> >     c. XSLT/XPath is well supported, and will be supported for a long
> >        time.  I cannot be sure how long the authors of Schematron,
> >        TREX, and RELAX will continue to support their initiatives.
> >
Schematron is a spec, not a program. Anyone can come up with a
schematron implementation (I'm inclined to call it a schematron schema
compiler) and several people have, all of them (the ones I know of) open

> > I am eager to be convinced that Options {1} and {2} have benefits over
> > Option {3}, but at the moment I am struggling to see what they might
> > be.  I look forward to your comments.  /Roger
> This was just a brief description of my experiences with Schematron and I
> wouldn't say it's a Best Practice because I know almost nothing about the
> other options but I look forward to see comments about the other options as
> well.
Sorry to be boring given your expectation of being "quite
controversial", but I simply agree that the schematron is a natural for

Obviously any of the three solutions would be limited to working with
the names of elements and attributes in the instance doc rather than
directly with their types. Access to XML Schema type information in
targetted in the XSLT 2.0 and XPath 2.0 Requirement WDs, and I'm sure
the DOM group have it on their agenda too.





These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.