The following is for consideration only. I am not proposing any specific action be taken at this time.
I've notice some inconsistencies in naming as pertains to referring to the category of properties versus traits. The XSL FO semantic model (e.g., see Formatting<http://www.w3.org/TR/2006/REC-xsl11-20061205/#d0e209>) refers to the following entities: - attributes - properties - traits Traits are further sub-divided into: - FO traits, i.e., the results of the refinement process - Area traits, also called "rendering traits" In the FOP implementation, I observe that the term "property" is used to refer to both FO properties and FO traits, i.e., both the input and the output of the refinement process. It may be useful to begin to distinguish between the input to the refinement process, i.e., FO properties, and the output of that process, i.e., FO traits. In particular, the (generally) private members of the various FO objects which have hitherto been referred to as "the value of properties relevant to fo:*", are probably more accurately described as FO traits, since it is they which store the results of the refinement process. In contrast, the value returned by Area.getTraits() denotes the Area (rendering) traits alone, and, should not, in general, include the FO traits (unless they happen to also be characterized as rendering traits). As an aside, the reason I'm noting this is because I needed to re-implement support for the writing-mode property and its related FO traits. The existing support for writing-mode used a bit of a hack on PropertyList, and, furthermore, did not properly implement the refinement semantics required to produce the writing-mode, inline-progression-direction, block-progression-direction, and shift-direction FO traits needed to support right-to-left writing modes. Regards, Glenn
