On Mon, 2003-11-24 at 19:47, Victor Mote wrote:
> FOP Developers:

> Proposal:
> I propose that public "get" methods be used to retrieve FO Tree property
> values, and that the data behind these values be made as private as
> possible. The methods should be given a name based on the XSL-FO Standard.
> For example, the "max-width" property should be accessed using the method
> "getMaxWidth". The values returned should be the "refined" values.

I have been thinking about this a bit and I would like to throw out a
few rambling observations:

Properties are defined in the spec, so there are a finite number of them
meaning that they map nicely in to an enumeration type*. Peter West had
written some stuff along that line. This allows us to get away from
object-and-compute-intensive String types. There are about 380 of these
in Peter's Mapping. Some 249 are simple attributes and the rest are
more complex, like space-after.optimum, space-after.miumum etc.

One train of thought I've had asks whether we need an atomic 'Property'
type alone or whether we can use a larger aggregate object type like
PropertyList that is a vector with each attribute value in a fixed
position. The idea here is that such a vector, something like a vTable,
can be merged quickly to resolve inheritence. 

v[FONT_FAMILY] = "sans-serif"
v[FONT_SIZE] -> "10pt"
v[...] -> ...

v has 400 entries or 250 entries and we use polymorphism somehow on the
complex properties

> Discussion:
> 1. The purpose here is to separate the storage of the property values from
> their presentation (API) to the rest of the system. This opens the door for
> later changes to the storage without disrupting the remainder of the system.

We need to contain the number of objects here. say with canonical
mapping of the property name strings. Possibly also use canonical
mapping of the attribute values too. How many times is "10pt" or
"bold" coded in an document ? Especially, given that patterns of 
FO are emitted by XSLT in other programs. Allows faster compares
when we can test with == rather than Object.equals( Object).

I had thought that the fact that all of the attributes are in the XSL-FO
Specification and that there are some simple structures used, I might
want to generate the property name list and some of the acccessors
like you have named them, automatically. Is there an XSL Schema for
XSL-FO, or would I just extract them from xml in the Spec document ? 

I can't say anything about how this stuff gets used, points 2 & 3.
I'd be interested in being involved in item 4.

> 2. This could perhaps be implemented for now only in FObj (??).
> 3. This is not directly relevant to the question, but needs to be addressed
> from the "big picture" standpoint. With the FO Tree mostly isolated, and
> LayoutStrategy implemented, the issue of whether a certain feature is
> implemented or not moves from the FO Tree to the specific LayoutStrategy.
> Each LayoutStrategy eventually needs to track which objects and properties
> it supports. The FO Tree should always store and return the data, without
> regard to whether it can be used or not. In the future, our properties.xml
> file, "compliance" page, and perhaps other things need to handle this. The
> LayoutStrategy needs to be the entity that reports on whether a feature is
> supported (perhaps using a scheme similar to properties.xml).
> 4. If accepted, this would be a great project for one of the new developers
> to tackle. I don't mean to volunteer anyone, but it might be a good "feet
> wet" project.
> My vote:
> +1
> Victor Mote

* we don' need no steenking enumeration type!

For years I thought the 'steenkin badges' quote originated with
WKRP's Dr. Johnny Fever.

Reply via email to