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 18:15:38 GMT
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
[snip]
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.

J.Pietschmann

Mime
View raw message