https://issues.apache.org/bugzilla/show_bug.cgi?id=51052

--- Comment #1 from Andreas L. Delmelle <adelme...@apache.org> 2011-04-13 
13:25:05 EDT ---
(In reply to comment #0)
> The issue is that a NPE is thrown when a retrieve-marker retrieves a marker
> with only text content, when the retrieve-marker is a child of a table-cell.
> The real problem here is that there is no validation done on the retrieve
> marker to ensure that the markers child is a valid child of the retrieve
> markers parent (excuse the tongue twister), see XSL section 6.13.5:

Indeed. Basic validation of child elements (i.e. FONode.validateChildNode()) is
skipped when the marker is cloned. That seems like an oversight.

> Though the spec doesn't specify how to handle this error, I am proposing that
> rather than throw an NPE, FOP logs a warning and ignores the marker. 

Exactly. That would remain consistent with the behavior during normal FO tree
building.
If some bare text is entered in a fo:table-cell (or basically any FO that
expects block-content), then it will be ignored, rather than reported as an
error. To remain consistent, we would have to match this behavior. So, if the
child node is a FOText and the retrieve-marker's parent is not a FObjMixed, we
should at most issue a warning, and assume 'no content'.

> The spec  doesn't specifically suggest that this kind of error is 
> recoverable, but others
> might agree that throwing an NPE isn't the "proper" way to deal with this
> error.

Definitely. Rule of thumb: a NPE is *always* wrong. :-)

> 
> I've attached an example test FO and I'll attach a patch shortly.

Thanks!

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to