On Sep 2, 2008, at 11:21, Jean-Fran├žois El Fouly wrote:

<snip />
Now if I run my test case against the trunk of FOP I get this error message:

*GRAVE: Exception
javax.xml.transform.TransformerException: org.apache.fop.fo.ValidationException: file:/D:/Java/fop-0.95beta/test-rtm.fo:533:112: Error(533/112): fo:retrieve-tab
le-marker is not a valid child element of fo:table-header.
*

Indeed, a shortcoming. There is one other case: the entire header/ footer can be contained within an fo:marker. This will currently also throw a ValidationException.

<snip />
The next step is where I'm puzzled and don't know how to proceed since the W3C recommendation and the example they give seem inconsistent with each other, while the error message FOP returns seems consistent with the recommendation:

*GRAVE: Exception
javax.xml.transform.TransformerException: org.apache.fop.fo.ValidationException: "{http://www.w3.org/1999/XSL/Format}table-row"; is not a valid child of "fo:mark
er"! (See position 557:21)
*
This error is consistent with the W3C TR: http://www.w3.org/TR/xsl/ #fo_marker
that says that the fo:marker contents is:

(#PCDATA|%inline; <http://www.w3.org/TR/xsl/#inline.fo.list>|% block; <http://www.w3.org/TR/xsl/#block.fo.list>)*

but it makes the example they give useless (indeed, neither inline nor block allow directly or indirectly table-row). And so I don't quite know where I'm allowed to go from here. (If I change a behaviour in *org.apache.fop.fo.flow.Marker.validateChildNode()* I may end up with something that works and fits the bill but is inconsistent with the TR).

The best way to go about it is probably to check the ancestry of the fo:marker before validating the child node. If the marker appears as a descendant of an arbitrary fo:table, then fo:table-row is allowed. However, we need to watch out because the same fo:marker could be retrieved into a static-content, in which case the fo:table-row would not be valid.

So, on the one hand, the validation rule needs to be relaxed. On the other, the regular marker-retrieval may not be disturbed...

What Vincent pointed out earlier does not seem entirely correct to me. The validation is independent from the parent fo, and so should not be delegated, but rather /deferred/ until the marker is retrieved/ reparented ... and even then, if a marker with a table-row ends up being retrieved by a normal retrieve-marker, I think this deserves only a serious warning about content being ignored/skipped. (The author of the stylesheet should probably take care to assign these markers to a special marker-class, which only gets retrieved by retrieve-table-marker.)



HTH!

Cheers

Andreas

Reply via email to