Redesign issues

["Peter B. West" <pb...@powerup.com.au>]

Arved Sandstrom wrote:
> 
> You're being absolutely honest, which is cool - I'll be absolutely honest
> also. It seems to me like the mainstream rewrite is in trouble. Very few
> people understand it or have [clearly] bought into it. This is no comment on
> its technical merits, by any means.
> 
> OTOH, only one person has been working on the alternative - you yourself,
> Peter. So what we really have is 3 projects: maintenance, rewrite, and
> alternative, and most of the committers and developers seem to be working on
> maintenance. Correct me if I'm wrong.

In a sense, we have four. Although xslfo-proc is being developed in
another place and language, you are still very much a part of this
development community, active of not. I nominate xslfo-proc as the
fourth project because, to the best of my knowledge, you and Eric are
taking a different approach to design again.  And the design, as you
point out, is the critical issue.  Whatever success you have with design 
in xslfo-proc should be of great interest here.

> The problems you describe in your email are symptoms, in my opinion. Forrest
> is irrelevant...we have bigger problems. In fact, pull vs push vs tree is
> also irrelevant, because that is dancing around the big issues -
> understanding the FO spec, and being able to implement it. Has anyone so
> far, for example, described a clear vision for properly handling keeps?

A comprehensive vision, no.  But what I consider to be some necessary
elements of the solution, yes.  And I firmly believe that the problem is 
comprehensively solvable.

>  No,
> they haven't. Does anyone here think the FO problem is non-deterministic?
> Raise your hands, please. :-) No? In which case, why (years after this
> project started) do we not have clear algorithms stating exactly what we
> will do in various situations?

This is the question that everyone has to answer.  Blind faith that that 
the problem can be solved by simply hurling onself at it is not enough. 
  I'm not saying that Keiron and Karen are in that situation, but I 
suspect that others are.  An elegant and comprehensive plan of attack, 
including a design approach that can confidently be expected to crack 
the toughest problems, may exist in their imaginations, but it needs to 
be made manifest before any sort of team attack can be made on the problems.

My impression though (and I am happy to have my ignorance corrected on
this) is that the redesign is being attempted piecemeal, without a broad
overview.  If I am correct in this, it would be largely explained by the
complexity of the problem, and the determination to retain as much as
possible of the existing code base, and therefore, of the existing 
design.  If I am wrong in this, it may be symptomatic of, in addition to 
  my laziness and obtuseness, inadequate top-level documentation 
(including diagramming) of the way the layout is attacked.

Whether or not those considerations actually apply in this case, if you
are using piecemeal design as a way to attack complexity, you must be
prepared to throw things away when they prove not to be fruitful, as
many things inevitably will.

>  I could care less at this point about SAX and
> DOM and pull and push - that's XML processing. Our FO processing algorithms,
> stated in design notes, should express independently of XML processing model
> how we will handle every FO situation.

I agree with you here.  By the time the layout is triggered in the
current model, the relevant part of the FO tree has been built, so the
layout engine is always working on a complete subtree.  However, it
seems to me that the existing design, and possibly the redesign, do not
take full advantage of this.  The alt.design has the advantage of being
based on an explicit, fully navigable tree structure.  However, that
structure is not, in itself, sufficient to express the relationships
needed for layout.  We have had discussions in the past about tree vs.
flat structures for the area tree.  I believe that both views are needed
simultaneously, and that the "flat" view can be obtained by running
"threads" of links through the tree to represent page-contiguous
elements for the resolution of keeps and space-specifiers, for example.

> I am not dismissing your concerns, Peter. I just think that we've got bigger
> ones. We are the committers; we need to decide once and for all what we
> intend to do. If it assuages your feelings any, I happen to be partial to
> your pull model - I am personally very comfortable with SAX, but I recognise
> that most are not.

Peter
-- 
Peter B. West  pbwest@powerup.com.au  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org