xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <grm7...@yahoo.com>
Subject Re: validateChildNode prevents extensions.
Date Sun, 29 Aug 2004 16:24:19 GMT
--- "J.Pietschmann" <j3322ptm@yahoo.de> wrote:

> 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.
> 

I thought of that (i.e., just make us a nice reference
implementation of the XSL standard), but PDF bookmarks
are just too popular -- as Simon noted, Docbook uses 
ours and RenderX's -- and the commercial
implementations regularly use extensions.  Certain
extensions that are relevant for only a particular
render-type are difficult to get into the
output-neutral XSL recommendation, so we may end up
having several anyway.

Also, as I understand it, extensions in RenderX and
AntennaHouse were the source for new official FO's in
the 1.1 spec (change bars, for example), so I don't
want FOP itself to lose that ability to be the source
of future FO's.  


> > 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

The content model *of that extension element*, i.e.,
the children of that extension element.  Not those of
the parents above it.  The content model for each FO
is defined within that FO.  We're basically building a
syntax-checking compiler, and it has to act as such.  

> 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.
> 

And what about its relative ordering within the
fo:block?  Or its cardinality?  These are also defined
in the content model.

Strictly speaking, an extension element cannot be the
child of an fo:block--the children of an fo:block are
defined by the rec, and they are all FO's.  You mean
the child of a particular processor's implementation
of fo:block, one whose content model has been modified
to accept certain extension elements.  OK, but if
that's the case, well, that fo:block's vCN() has
already determined the extension element to be valid.

As I said, the only difference between an formatting
object and and extension element is that the latter
hasn't yet been blessed by the W3C.  Their processing
and validation is the same.  Change bars = 1.0
extension element (RenderX/AH), but a 1.1 formatting
object.

Content models define the valid children of an
formatting object, extension or otherwise.  

> >  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*.
> 

No, because DTD content models are always defined for
the higher-level (i.e., parent) node.  And it's
strange to suggest that a "candidate FO" can/should be
able to located anywhere, given that all the actual 56
FO's have precise ordering.   


> >  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. 

The proper model is the Rec, and time and again,
indeed for all the FO's, the content model is defined
for the parents, not for the children.  FinnBlock.java
also has to define the LayoutManager that will handle
it, and in certain cases, the FO's below it--how it
will work with them.  This is simply not dynamically
additive.

You have a new FO, you're going to need to code for
them--including ordering and cardinality--in those
parents that accept them, and subsequently the Layout
which has to handle them.

> 
>  From the viewpoint of a FO element, any elements
> (and
> attributes) from other namespaces are valid and will
> be
> instantiated. 

Returning to the old method is not really an option. 
That's what was causing CCE and NPE's throughout the
system, whenever the FO was invalidly ordered.  The
subsequent error checking in all the methods was
clogging business logic throughout; furthermore
instantiation would otherwise raise other errors, as,
say, fo:layout-master-set tries to read from its
fo:root parent but is instead ends up reading from an
fo:list-item.

If the current node is an fo:list-item and the
incoming node represents an fo:layout-master-set,
raise the exception immediately before you even get to
instantiate the fo:layout-master-set.  Nothing is more
solid and foolproof than that.

Glen


Mime
View raw message