--- Glen Mazza <[EMAIL PROTECTED]> wrote:
> Jeremias,
> This should not be done.  If someone has a problem
> with it--and I've never heard a complaint--they can
> send an email to xsl-editors, for them to adjust the
> content model for fo:table accordingly.  (If they
> don't, they don't.)

To elaborate, I also frequently have problems with
certain content models, but what I do is send requests
to the xsl-editors list[1] when I have them (for
example, [2, #61], and several others).  I think it
would be best for you to do that before considering
making the change with FOP.  It may also encourage
others to endorse your suggestion on the ML.

But making the change without informing the W3C of
what you see as an error doesn't help improve the
standard.  Also, IMO we should be encouraging unhappy
users to register their complaints with the W3C so
that they will indeed make these changes.  (10, 15
complaints, they will!)  In this way, FOP plays the
role of a true reference implementation, with a nice
circular, ongoing feedback with the W3C, and all
FOP-accepted stylesheets will be guaranteed to work
with other processors.

We validate also to show newbie users what they are
doing wrong.  It gives nice correction and feedback to
the user, just like compilation errors in Java give
feedback to newbie developers.  Validation serves a
good purpose.



> Note that the editors are very reasonable about
> this--for example, fo:page-sequence-wrapper and
> fo:wrapper are allowed to have no children for
> programmatic convenience, even though it doesn't
> make
> sense for these items to be empty.

And in #61, you can see I don't like empty
fo:page-sequence-wrappers or fo:wrappers either.  ;)

> BTW, what is FONode.removeChild() for anyway?  Why
> is
> this helpful--we haven't needed such a method for
> years.

Sorry, I was wrong here--we have indeed needed such a
method, until about December ([3], emails 9, 7, 6). 
We used to have addLayoutManager() in the FO's in
which the FO would determine whether or not it was
empty, and if not, attach itself to a Layout Manager. 
(Email #9)  I kind of preferred this implementation,
as it allowed us to keep the internal state of each FO
internal, rather than need to expose its internal
variables to another object that would subsequently
read inside it to make the empty-or-not determination
for the FO.

Simon moved us away from that (Email #7 of [3])
because he didn't want the FO's to have knowledge of
layout managers, and wanted to move us from (1) having
the FO decide whether or not to attach itself to a LM
to (2) having a layout manager decide whether or not
to process an empty FO.  This is not my preferred
implementation, but it seems an acceptable

But your removeNode() function seems to be bouncing
back to the original implementation now: let the FO
decide.  Can we make a decision and settle on one or
the other here?  Do we really have to do both?

Also, my main problem with Simon's implementation, was
that (as mentioned above) the FO's needed to expose
their internal state more to the LayoutManagerMaker
object so the latter could determine if it needed to
process that FO.  I think Simon saw that a little as
well, and what I recommended in Email #6 was that we
have an boolean FONode.isEmpty() that the
LayoutManagerMakers can read, and if it returns true,
to not process the FO.  Question: can we use a boolean
isEmpty() instead of your removeNode()?  We can then
much better encapsulate each FO (i.e., instead of
having a LMM read variable a, b, and c of an FO to see
if it needs processing, it can just check isEmpty()).

Sorry for the long post.


[3] http://marc.theaimsgroup.com/?t=110286102900001&r=1&w=2

Reply via email to