RE: [REQUEST FOR FEEDBACK] Keep properties and other "ambivalent" properties

[Philippe Lavoie <ph...@cactus.ca>]

In C++ I do something like

	const int auto=0;
	const int always=-1;

In XML, you use entities for that, no ?

	<!DOCTYPE page [
	 <!ENTITY auto "0">
	 <!ENTITY always "1">
	]>

so you can do

<generic-keep>&auto;</generic-keep>

However, why not just use an attribute to describe special cases ?  (I
prefer that method)

	<generic-keep always="true"/>
	<generic-keep>23</generic-keep>

In my old C code days, I know that I hated that I had to remember what to
use -1 or whatever for special meanings. I really liked the C++ approach
which is to overload the function with different arguments and in the rare
case I need something more precise I use the overloaded version as in 

	function(int value);
	function(int value,boolean auto, boolean always);

With that scheme I could also optimize the body function or just call
function(value,false,false) if speed was not an issue.


Anyway, not sure I know what you want to do :)

Sorry for the noise

Phil

PS Why don't you use Schema to define a general properties?

-----Original Message-----
From: Karen Lease [mailto:klease@club-internet.fr]
Sent: Wednesday, December 13, 2000 6:22 PM
To: fop-dev@xml.apache.org
Subject: [REQUEST FOR FEEDBACK] Keep properties and other "ambivalent"
properties


Hi all,

As the next step on the road to bringing FOP up to standard with respect
to properties, I'm requesting feedback on some property specification
issues.

The latest foproperties.xml includes a partially commented out
definition for a GenericKeep property which looks like this:

  <property type="generic">
    <name>generic-keep</name>
    <class-name>GenericKeep</class-name>
    <datatype>Number</datatype>
    <keyword-equiv match="auto" eval="true">0</keyword-equiv>
    <keyword-equiv match="always" eval="true">-1</keyword-equiv>
....

The problem with this idea is that the XSL FO draft doesn't say anything
about which values of a Number are allowed. So if we arbitrarily say
"auto" is 0 and "always" is -1, a poor unsuspecting user could use these
as number values and get unexpected results.

The ideal would be to say something like this:

  <property type="generic">
    <name>generic-keep</name>
    <class-name>GenericKeep</class-name>
    <datatype>Number</datatype>
    <enumeration>
        <value const="AUTO">auto</value>
        <value const="ALWAYS">always</value>
    </enumeration>

But we can't store this as a simple Number object. We would need an
"EnumOrNumber" object with a method like "isEnum()" or "isEnumValue(int
eval)". If the value is specified as a '3' for example, isEnum() returns
false and intValue() returns 3.
If the value is specified as 'auto', isEnum() returns true and we can
then get the enum value and compare it to GenericKeep.AUTO for example.

EnumOrNumber could be defined as a subclass of Number and stored in
NumberProperty objects. But then we'd have to downcast it to use the
isEnum methods, which isn't very clean.

In the XSL specification there are 9 properties specified as <number> or
<integer> and one or more enumerated values, plus the <keep> and
<precedence> parts of the compound value types for Keep and Space.
We currently implement only 2 of these, max-repeats and
initial-page-number. To get around the EnumOrNumber problem, these are
defined as "String" types and the code that uses them has to finish off
the parsing.

Length
There are also quite a lot of properties which are basically Length but
have one or more enumerated values possible. The only one we handle
systematically (at least we read it and store it) is "auto"  if the
"<auto-ok/>" tag is present on a Length type property definition. The
Length class defines an "isAuto()" method that can be used to check
whether the property was specified as "auto". But this is really just a
particular case of the more general issue. Some Length values can have
enumerated values of "none", "scale-to-fit", "use-font-metrics", "top"
etc depending on the property. Again, a general solution would be to
define a subclass of Length called EnumOrLength and use it to store
either a Length or an Enum. Code using such "ambivalent" properties
would have to check the enumerated values first and then if none were
set, use the base datatype.
EnumOrLength values would be stored in LengthProperty objects and
returned by getLength(). This is actually cleaner than the EnumOrNumber
class since the base class Length could define an isEnum() method.

Your turn now...

-Karen

-----------------
Karen Lease
SPX Valley Forge/France