On Dec 18, 2007, at 13:17, Vincent Hennebert wrote:

<snip />
IIUC, this check isn’t necessary? If test children weren’t allowed this
would have been caught by the validateChildNode method?


No, because validateChildNode() is not called for text-nodes.

Hmmm, this is unfortunate IMO. That makes validation unreliable, and
that forces to implement hacks like in Wrapper.

Unfortunate, maybe, but I'm not sure why implementing an override for a method that contains behavior that is specific to instances of the Wrapper class should be considered a hack...? FTM I'm trying to fit it in in the current design as cleanly as possible. It's good to see that the question is raised, instead of my changes being blindly accepted.

Then again, as I indicated earlier, something seems fishy/awkward about hardcoding the validation rules in the FOs, since this leaves too little room for adding extensions.

IMO, we need some way of registering valid child nodes at runtime. The default rules in the Recommendation can be fixed at compile time, but there is also still room for improvement.

Note, for instance, that there's a significant number of FOs that allow no children, and this leads to a lot of code-duplication, as they all individually implement the method like:

protected void validateChildNode(...) throws ValidationException {
  invalidChildError(..., "XSL Content Model: empty");
}


I was thinking in the direction of using a dummy marker interface, so the duplicate overrides can all be removed, and consolidated in the superclass.

For example:

public interface EmptyFObj { //empty body, only used as a marker interface, like Cloneable or Serializable }
...

public class ExternalGraphic extends AbstractGraphics implements EmptyFObj { ... }
...

in FObj.validateChildNode():

if (this instanceof EmptyFObj) {
  invalidChildError(..., "XSL Content Model: empty");
}

If, on top of that, extension nodes are validated separately through a different mechanism, this would still make it possible for a fo:external-graphic to have child nodes, only none in the FO namespace.



One could argue that the default characters() event should also do
some
form of validation, but that could turn out to be very tricky. The SAX
parser is obliged to report *all* characters (including possible
ignorable whitespace). We would already need to perform
space-normalization here to make sure there really are stray characters
in places where they do not belong...

Well it’s not the same kind of normalization as required by the
Recommendation. For objects accepting mixed content we would accept any
kind of text node, and the proper normalization would indeed be done
later.
For the other objects we just need to know if the text node contains XML whitespace only (space, tab, line-feed, carriage-return). Something like
String.trim().length() == 0 should be enough for the validation. WDYT?

Hmm... but in some cases, the white-space could be significant (depending on the FO properties white-space-treatment/white-space- collapse/linefeed-treatment of the containing block, if any).

Take:

<fo:block white-space-treatment="preserve">
**<fo:block-container>
****<fo:wrapper>
******<fo:block>

The *'s are preserved space-characters. The first two are allowed, the other six are, very strictly speaking an error (albeit, an easily recoverable one).


Cheers

Andreas

Reply via email to