--- "J.Pietschmann" <[EMAIL PROTECTED]> 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
