Glen Mazza wrote:
There shouldn't be extensions hardcoded
I thought of that (i.e., just make us a nice reference
implementation of the XSL standard), but PDF bookmarks
are just too popular

I didn't meant the bookmark extension should be discarded,
I meant the code should be pulled out of the core into a
separate, loadable extension, using the same mechanisms as
other extensions.

The content model *of that extension element*,

Wrong, the extension writer also decides in which FO elements his extension elements can appear. *You* certainly can't do this now.

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

The Java object corresponding to the extension element should have access to the part of the FO tree which had been already constructed, including preceding siblings. Constraints involving elements from the FO namespace like "must precede any fo:* elements" are a bit difficult, but there are ways around this (registered callbacks, for example).

The proper model is the Rec,

This means you want to disallow *all* extensions except as child of instream-foreign-object. This is a somewhat strange contradiction to your stance with respect to the bookmark extension.

You have a new FO, you're going to need to code for
them--including ordering and cardinality--in those
parents that accept them,

This does *not* necessarily mean that *you* should arrange that the extension writer has to replace core FO classes. In fact do either: 1. Declare FOP wont support extensions except in instream-foreign-object, ever, or 2. Provide hooks so that extension writers can get their extensions running with FOP, with or without extensive validation of the extended content model, but at least *without* having to rewrite and replace core FO classes. The crude middle way to allow extensions but make it extra hard for developers to get them working, *and* make it nearly impossible for independently developed extensions to cooperate (as Finn already explained to you several times), is, well, crude, hard, and unnecessary.

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.

*sigh* I should have time to do it myself. I don't see why content model checking and drop-in extensions have to be mutually exclusive.

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.

This does not mean you have to summarily reject a finnbock:change-bar on the same grounds.


Reply via email to