> Yep, that's what I was referring to, and AFAICT, it is not mandated
> that the change-bar-begin and the corresponding change-bar-end appear
> in the same flow/page-sequence.
yes, it can occur across page-sequences, etc.
> Seems reasonable, although... validateChildNode() is more meant to
> take care of very specific cases, mentioned in the definition of the
> content model. Now I'm thinking: a change-bar-* is a neutral item that
> is basically allowed anywhere, except as a child/descendant of a very
> limited set of FOs that cannot appear as descendants of an fo:flow or
> The requirement of a flow/static-content ancestor is specific to the
> change-bar-* nodes, not to their parent/ancestor, so I'm not entirely
> sure whether FObj is the right place to enforce that rule...
Yes, that rule is enforced in the ChangeBar class' startNode(), which is the
base class for the ChangeBarBegin and ChangeBarEnd classes.
But the validateChildNode() has to accept change-bar-begin and change-bar-end
children for all nodes in order to allow them to occur at the allowed places.
Thus, as I see it, either this has to be added to all validateChildNode()
methods, or validation of children for an arbitrary element has to be split in
checking for elements that may always be children (the change bars currently)
and element specific checks mandated by the content model of each node.
I used the later approach.
If all elements that may be in a flow call a common validateChildNode() (via
super()), then the code could be moved there (I didn't check).
Dr.-Ing. Stephan Thesing
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01