Oleg Tkachenko wrote:
Peter B. West wrote:
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;)* ?
How about:
FoXMLEvent ev = expectStartElement
(FObjectSets.normalPcdat
Peter B. West wrote:
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;)* ?
How about:
FoXMLEvent ev = expectStartElement
(FObjectSets.normalPcdataBlockInlineSet,
Oleg Tkachenko wrote:
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,
How about:
/**
* Expect that the next element will be a STARTELEMENT for one of the
* flow objects wh
Oleg,
It's not a question of being a better way to validate, per se. What I'm
saying is that it is a better way to process complex XML of fixed
structure. The ability to validate is a side-effect of an explicit
top-down processing structure, which effectively allows you to read the
structure
Peter B. West wrote:
BALI: In Memoriam
In a pull model, as distinct from the peephole processing model
encouraged by SAX, this is easy, because you know where you are at all
times; e.g., whether you are within an fo:flow, or more specifically,
whether you are descending within an "out-of-line"
Chuck Paussa wrote:
I believe that the schematron folks are working on a schematron
validator that works as an extension to the schema
It's done already, schematron schema can be embedded into xml schema. This
actually allows double validation against both schemas.
If anyone wants to take on
Oleg and Peter,
Here's the latest iteration of the fo schema. Could someone commit it?
The only change is to allow % in length attributes.
I believe that the schematron folks are working on a schematron
validator that works as an extension to the schema (By adding schematron
extensions to the
Peter B. West wrote:
In a pull model, as distinct from the peephole processing model
encouraged by SAX, this is easy, because you know where you are at all
times; e.g., whether you are within an fo:flow, or more specifically,
whether you are descending within an "out-of-line" formatting object.
BALI: In Memoriam
Oleg Tkachenko wrote:
...
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 occ
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 con
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
conse
Hello!
I've been thinking about fop users most confused questions and then
about general solution for detection input tree related errors and
finally I arrived at the old idea (raised already on the list) of input
tree validation.
Indeed, at the moment fop doesn't validate entire input tree, bu
12 matches
Mail list logo
