Glen Mazza wrote:
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

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

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 to have different child
nodes from FOP's

There is no "Finn's" 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.


Reply via email to