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 . 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):
<ns uri="http://www.w3.org/1999/XSL/Format" prefix="fo"/>
<pattern name="Structure Checks">
<key name="masters" path="@master-name"/>
<assert test="ancestor::fo:flow[@flow-name='xsl-region-body' or
fo:footnote must occur as a descendant of a flow that is assigned to a region-body
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;)* ?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 FoRoot.java
Multiconn International, Israel
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]