Oleg,

I don't know schematron, so we may be talking at cross-purposes here. The approach I have taken in the alt-design is to change from push model processing to pull model. In a push model, the focus of processing is the individual parsing event. When such an event occurs, all of the consequences of the event occur at that point. The process in inherently obscure, and is one of the factors that makes the Fop code so difficult to comprehend. It's not just Fop, of course. SAX is based on push processing.

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

// Look for layout-master-set
try {
ev = xmlevents.expectStartElement
(XMLNamespaces.XSLNSpaceIndex, "layout-master-set",
XMLEvent.DISCARD_W_SPACE);
} catch (NoSuchElementException e) {
throw new FOPException(e);
}
// Process the layout-master-set
try {
layoutMasters = new FoLayoutMasterSet(foTree, this, ev);
}
...
}
// Look for optional declarations
try {
xmlevents.expectStartElement
(XMLNamespaces.XSLNSpaceIndex, "declarations",
XMLEvent.DISCARD_W_SPACE);
// process the declarations here
xmlevents.getEndElement
(XMLNamespaces.XSLNSpaceIndex, "declarations");
} catch (NoSuchElementException e) {
// Take no notice - declarations is optional
}

and in FoLayoutMasterSet.java

private static final UriLocalName[] simpleOrSequenceMaster = {
new UriLocalName
(XMLNamespaces.XSLNSpaceIndex, "simple-page-master"),
new UriLocalName
(XMLNamespaces.XSLNSpaceIndex, "page-sequence-master")
};
...
XMLEvent ev =
xmlevents.expectStartElement
(simpleOrSequenceMaster, XMLEvent.DISCARD_W_SPACE);
localName = ev.getLocalName();
if (localName.equals("simple-page-master")) {
// Process a simple-page-master
} else if (localName.equals("page-sequence-master")) {
// Process a page-sequence-master
}

etc...

The point is that specific types of XML event are sought within a particular context that mirrors and makes manifest the necessary structure of the input. This allows for validation at the point of expectation. It provides at least part of the context for testing the complex validation requirements of FO, without the necessity of any completely general system.

Peter


Oleg Tkachenko wrote:
...

Hence my proposition - lets create (potentially optional?) validation module with duties to validate input tree and report errors/warnings/suggestions in human readable (or even localizable) form and lets set free other modules from validation concerns. I believe it could be much more robust and easy to implement and maintain approach.

Here is my thoughts about possible validation implementation:
Usual xml validation against dtd or schema (and we have XEP as an example - they does validate against self-made xsl-fo dtd). Well, but xsl-fo is such a beast that cannot be expressed in dtd and even in xml schema as it defines a lot of cooccurence constraints like mutually exclusive internal-destination and external-destination of fo:basic-link. And dtd/schema validation error messages are far from poor user understanding, so schematron come into my mind. Why not? It's quite simple to create schematron schema for xsl-fo, define understandable asserts, then compile it into xsl stylesheet (or even into java class using xalan's xsltc) during fop building and use it as optional sax filter at run-rime.
--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


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

Reply via email to