Provided the extension namespace isn't already hardcoded into FOP (like the fox: one).
There shouldn't be extensions hardcoded into the FOP core, at least in the long term.
Errr, elements can't "validate themselves", because the validity of an element is defined only by the parent.
The extension writer decides the content model, and if an extension element is supposed to be child of a fo:block only, the corresponding Java object has to get its parent and verify its actually a fo:block.
The recommendation declares, via the content models, which children are valid for each parent, not vice-versa.
True for elements from the FO namespace *only*.
This logic is naturally (and much more cleanly) stored with the parent in the OO world, allowing Finn's block.java to have different child nodes from FOP's block.java.
There is no "Finn's block.java" in the proper model of doing extensions. An extension writer should only write the extension. The FOP core must 1. Provide a discovery mechanism for the extension. The service file used for this purpose in the maintenance branch can be easily extended just by dropping the extension jar into the classpath. 2. A configuration mechanism for the extension both for default and user supplied values. We don't have this currently. 3. A hook for the extension element factory. Works nicely. 4. A hook for validating the extended content model. 5. Hooks for doing layout and rendering. Especially the API for the last will take some iterations, but this doesn't mean
Furthermore, such a child-level validation would require the kid to be instantiated first. vCN() stops instantiation of the kid from ever occurring if it would be invalid to begin with.
From the viewpoint of a FO element, any elements (and attributes) from other namespaces are valid and will be instantiated. Then the foreign children get a chance to validate themselves. Granted, visible foreign content should be exclusively used through instream-foreign-object, but this breaks down for extensions like Karen's extension elements shown before or after page breaks.
J.Pietschmann
