xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.Pietschmann" <j3322...@yahoo.de>
Subject Re: validateChildNode prevents extensions.
Date Sun, 29 Aug 2004 14:44:23 GMT
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
> 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

Mime
View raw message