Peter B. West wrote:

I don't know schematron, so we may be talking at cross-purposes here.
Well, schematron is extremely simple while powerful rule-based schema language, see the overview [1]. I'd say if you know xslt and xpath, you know schematron.
For example, consider the following xsl constraint:
"It is an error if the fo:footnote occurs as a descendant of a flow that is not assigned to a region-body".
So, simple to say, fo:float must be descendant of flow, which has flow-name
either equal to reserved "xsl-region-body" or which is assigned to fo:region-body object. That's cooccurence constraint and therefore cannot be expressed neither in xml schema nor in dtd. fop 0.20.4 doesn't verify this one also, but says "[ERROR]text outside block area1" during FOText layout.
Schematron schema for such validation could be as follows (well, it's neither optimized nor full one as ignores fo:static-content):

<schema xmlns="";>
<ns uri=""; prefix="fo"/>
<pattern name="Structure Checks">
<rule context="fo:simple-page-master">
<key name="masters" path="@master-name"/>
<rule context="fo:footnote">
<assert test="ancestor::fo:flow[@flow-name='xsl-region-body' or
key('masters', current()/ancestor::fo:page-sequence/@master-reference)/fo:region-body/@region-name=current()/ancestor::fo:flow/@flow-name]">
fo:footnote must occur as a descendant of a flow that is assigned to a region-body

My approach is built on SAX, but puts a buffer between parsing and tree
building.  There's a cost for that, but the cost of parsing is small in
relation to the overall downstream processing costs.  The end result is
that specific types of XML events can be pulled out of the buffer by
downstream processes.  E.g. in
I like pull parsing model in general, but how do you manage with not such strict content model as fo:root have, e.g. fo:block with (#PCDATA|%inline;|%block;)* ?

Oleg Tkachenko
eXperanto team
Multiconn International, Israel

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to