arved 02/03/17 09:24:11
Added: docs/design/alt.design AbsolutePosition.png
BorderCommonStyle.png parserPersistence.png
processPlumbing.png Properties.png
PropertyClasses.png PropertyConsts.png
PropertyStaticsOverview.png
property-super-classes-full.png PropNames.png
SAXParsing.png VerticalAlign.png
XML-event-buffer.png XMLEventQueue.png
xmlevent-queue.png AbsolutePosition.dia
processPlumbing.dia Properties.dia
PropertyClasses.dia PropertyConsts.dia
PropertyStaticsOverview.dia
property-super-classes-full.dia PropNames.dia
SAXParsing.dia VerticalAlign.dia
XML-event-buffer.dia XMLEventQueue.dia
xmlevent-queue.dia AbsolutePosition.png.xml
alt.properties.xml book.xml
BorderCommonStyle.png.xml classes-overview.xml
properties-classes.xml Properties.png.xml
PropertyConsts.png.xml propertyExpressions.xml
PropNames.png.xml VerticalAlign.png.xml
xml-parsing.xml dirlist.html
Log:
Extra design commentary
Revision Changes Path
1.1 xml-fop/docs/design/alt.design/AbsolutePosition.png
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/BorderCommonStyle.png
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/parserPersistence.png
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/processPlumbing.png
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/Properties.png
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/PropertyClasses.png
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/PropertyConsts.png
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/PropertyStaticsOverview.png
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/property-super-classes-full.png
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/PropNames.png
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/SAXParsing.png
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/VerticalAlign.png
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/XML-event-buffer.png
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/XMLEventQueue.png
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/xmlevent-queue.png
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/AbsolutePosition.dia
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/processPlumbing.dia
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/Properties.dia
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/PropertyClasses.dia
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/PropertyConsts.dia
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/PropertyStaticsOverview.dia
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/property-super-classes-full.dia
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/PropNames.dia
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/SAXParsing.dia
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/VerticalAlign.dia
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/XML-event-buffer.dia
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/XMLEventQueue.dia
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/xmlevent-queue.dia
<<Binary file>>
1.1 xml-fop/docs/design/alt.design/AbsolutePosition.png.xml
Index: AbsolutePosition.png.xml
===================================================================
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- $Id: AbsolutePosition.png.xml,v 1.1 2002-01-05 14:46:32+10 pbw
Exp pbw $ -->
<!--
<!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd">
-->
<document>
<header>
<title>AbsolutePosition diagram</title>
<authors>
<person id="pbw" name="Peter B. West"
email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<!-- one of (anchor s1) -->
<s1 title="Properties$AbsolutePosition">
<figure src="AbsolutePosition.png" alt="AbsolutePosition diagram"/>
</s1>
</body>
</document>
1.1 xml-fop/docs/design/alt.design/alt.properties.xml
Index: alt.properties.xml
===================================================================
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- $Id: alt.properties.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ -->
<!--
<!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd">
-->
<document>
<header>
<title>Implementing Properties</title>
<authors>
<person id="pbw" name="Peter B. West" email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<!-- one of (anchor s1) -->
<s1 title="An alternative properties implementation">
<note>
The following discussion focusses on the relationship between
Flow Objects in the Flow Object tree, and properties. There
is no (or only passing) discussion of the relationship between
properties and traits, and by extension, between properties
and the Area tree. The discussion is illustrated with some
pseudo-UML diagrams.
</note>
<p>
Property handling is complex and expensive. Varying numbers of
properties apply to individual Flow Objects
<strong>(FOs)</strong> in the <strong>FO
tree </strong> but any property may effectively be
assigned a value on any element of the tree. If that property
is inheritable, its defined value will then be available to
any children of the defining FO.
</p>
<note>
<em>(XSL 1.0 Rec)</em> <strong>5.1.4 Inheritance</strong>
...The inheritable properties can be placed on any formatting
object.
</note>
<p>
Even if the value is not inheritable, it may be accessed by
its children through the <code>inherit</code> keyword or the
<code>from-parent()</code> core function, and potentially by
any of its descendents through the
<code>from-nearest-specified-value()</code> core function.
</p>
<p>
In addition to the assigned values of properties, almost every
property has an <strong>initial value</strong> which is used
when no value has been assigned.
</p>
<s2 title="The history problem">
</s2>
<p>
The difficulty and expense of handling properties comes from
this univeral inheritance possibility. The list of properties
which are assigned values on any particular <em>FO</em>
element will not generally be large, but a current value is
required for each property which applies to the <em>FO</em>
being processed.
</p>
<p>
The environment from which these values may be selected
includes, for each <em>FO</em>, for each applicable property,
the value assigned on this <em>FO</em>, the value which
applied to the parent of this <em>FO</em>, the nearest value
specified on an ancestor of this element, and the initial
value of the property.
</p>
<s2 title="Data requirement and structure">
<p>
This determines the minimum set of properties and associated
property value assignments that is necessary for the
processing of any individual <em>FO</em>. Implicit in this
set is the set of properties and associated values,
effective on the current <em>FO</em>, that were assigned on
that <em>FO</em>.
</p>
<p>
This minimum requirement - the initial value, the
nearest ancestor specified value, the parent computed value
and the value assigned to the current element -
suggests a stack implementation.
</p>
</s2>
<s2 title="Stack considerations">
<p>
One possibility is to push to the stack only a minimal set
of required elements. When a value is assigned, the
relevant form or forms of that value (specified, computed,
actual) are pushed onto the stack. As long as each
<em>FO</em> maintains a list of the properties which were
assigned from it, the value can be popped when the focus of
FO processing retreats back up the <em>FO</em> tree.
</p>
<p>
The complication is that, for elements which are not
automatically inherited, when an <em>FO</em> is encountered
which does <strong>not</strong> assign a value to the
property, the initial value must either be already at the
top of the stack or be pushed onto the stack.
</p>
<p>
As a first approach, the simplest procedure may be to push a
current value onto the stack for every element - initial
values for non-inherited properties and the parental value
otherwise. Then perform any processing of assigned values.
This simplifies program logic at what is hopefully a small
cost in memory and processing time. It may be tuned in a
later iteration.
</p>
<s3 title="Stack implementation">
<p>
Initial attempts at this implementation have used
<code>LinkedList</code>s as the stacks, on the assumption
that
</p>
<sl>
<!-- one of (dl sl ul ol li) -->
<li>random access would not be required</li>
<li>
pushing and popping of list elements requires nearly
constant (low) time
</li>
<li> no penalty for first addition to an empty list</li>
<li>efficient access to both bottom and top of stack</li>
</sl>
<p>
However, it may be required to perform stack access
operations from an arbitrary place on the stack, in which
case it would probably be more efficient to use
<code>ArrayList</code>s instead.
</p>
</s3>
</s2>
<s2 title="Class vs instance">
<p>
An individual stack would contain values for a particular
property, and the context of the stack is the property class
as a whole. The property instances would be represented by
the individual values on the stack. If properties are to be
represented as instantiations of the class, the stack
entries would presumably be references to, or at least
referenced from, individual property objects. However, the
most important information about individual property
instances is the value assigned, and the relationship of
this property object to its ancestors and its descendents.
Other information would include the ownership of a property
instance by a particular <em>FO</em>, and, in the other
direction, the membership of the property in the set of
properties for which an <em>FO</em> has defined values.
</p>
<p>
In the presence of a stack, however, none of this required
information mandates the instantiation of properties. All
of the information mentioned so far can be effectively
represented by a stack position and a link to an
<em>FO</em>. If the property stack is maintained in
parallel with a stack of <em>FOs</em>, even that link is
implicit in the stack position.
</p>
</s2>
<p>
<strong>Next:</strong> <link href= "classes-overview.html"
>property classes overview.</link>
</p>
</s1>
</body>
</document>
1.1 xml-fop/docs/design/alt.design/book.xml
Index: book.xml
===================================================================
<?xml version="1.0"?>
<book title="FOP New Design Notes" copyright="2001-2002 The Apache Software
Foundation">
<external href="http://xml.apache.org/fop/"; label="About FOP"/>
<separator/>
<external href="../index.html" label="NEW DESIGN" />
<separator/>
<page id="index" label="alt.properties" source="alt.properties.xml"/>
<page id="classes-overview" label="Classes overview"
source="classes-overview.xml"/>
<page id="properties-classes" label="Properties classes"
source="properties-classes.xml"/>
<page id="Properties" label="Properties" source="Properties.png.xml"/>
<page id="PropertyConsts" label="PropertyConsts" source="PropertyConsts.png.xml"/>
<page id="PropNames" label="PropNames" source="PropNames.png.xml"/>
<page id="AbsolutePosition" label="AbsolutePosition"
source="AbsolutePosition.png.xml"/>
<page id="VerticalAlign" label="VerticalAlign" source="VerticalAlign.png.xml"/>
<page id="BorderCommonStyle" label="BorderCommonStyle"
source="BorderCommonStyle.png.xml"/>
<separator/>
<page id="xml-parsing" label="XML parsing" source="xml-parsing.xml"/>
<separator/>
<page id="property-parsing" label="Property parsing"
source="propertyExpressions.xml"/>
</book>
1.1 xml-fop/docs/design/alt.design/BorderCommonStyle.png.xml
Index: BorderCommonStyle.png.xml
===================================================================
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- $Id: BorderCommonStyle.png.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ -->
<!--
<!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd">
-->
<document>
<header>
<title>BorderCommonStyle diagram</title>
<authors>
<person id="pbw" name="Peter B. West"
email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<!-- one of (anchor s1) -->
<s1 title="Properties$BorderCommonStyle">
<figure src="BorderCommonStyle.png" alt="BorderCommonStyle diagram"/>
</s1>
</body>
</document>
1.1 xml-fop/docs/design/alt.design/classes-overview.xml
Index: classes-overview.xml
===================================================================
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- $Id: classes-overview.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ -->
<!--
<!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd">
-->
<document>
<header>
<title>Property classes overview</title>
<authors>
<person id="pbw" name="Peter B. West"
email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<!-- one of (anchor s1) -->
<s1 title="Classes overview">
<s2 title="The class of all properties">
<p>
If individual properties can have a "virtual reality" on the
stack, where is the stack itself to be instantiated? One
possibility is to have the stacks as <code>static</code>
data structures within the individual property classes.
However, the reduction of individual property instances to
stack entries allows the possibility of further
virtualization of property classes. If the individual
properties can be represented by an integer, i.e. a
<code>static final int</code>, the set of individual
property stacks can be collected together into one array.
Where to put such an overall collection? Creating an
�ber-class to accommodate everything that applies to
property classes as a whole allows this array to be defined
as a <em><code>static final</code> something[]</em>.
</p>
</s2>
<s2 title="The overall property classes">
<p>
This approach has been taken for the experimental code.
Rather than simply creating a overall class containing
common elements of properties and acting as a superclass,
advantage has been taken of the facility for nesting of
top-level classes. All of the individual property classes
are nested within the <code>Properties</code> class.
This has advantages and disadvantages.
</p>
<dl>
<dt>Disadvantages</dt>
<dd>
The file becomes extremely cumbersome. This can cause
problems with "intelligent" editors. E.g.
<em>XEmacs</em> syntax highlighting virtually grinds to a
halt with the current version of this file.<br/> <br/>
Possible problems with IDEs. There may be speed problems
or even overflow problems with various IDEs. The current
version of this and related files had only been tried with
the <em>[X]Emacs JDE</em> environment, without difficulties
apart from the editor speed problems mentioned
above.<br/> <br/>
Retro look and feel. Not the done Java thing.<br/> <br/>
</dd>
<dt>Advantages</dt>
<dd>
Everything to do with properties in the one place (more or
less.)<br/> <br/>
Eliminates the need for a large part of the (sometimes)
necessary evil of code generation. The One Big File of
<code>foproperties.xml</code>, with its ancillary xsl, is
absorbed into the One Bigger File of
<code>Properties.java</code>. The huge advantage of this
is that it <strong>is</strong> Java.
</dd>
</dl>
</s2>
<s2 title="The property information classes">
<p>
In fact, in order to keep the size of the file down to more
a more manageable level, the property information classes of
static data and methods have been split tentatively into
three:
</p>
<figure src="PropertyStaticsOverview.png" alt="Top level
property classes"/>
<dl>
<dt><link href="PropNames.html">PropNames</link></dt>
<dd>
Contains an array, <code>propertyNames</code>, of the names of
all properties, and a set of enumeration constants, one
for each property name in the <code>PropertyNames</code>
array. These constants index the name of the properties
in <code>propertyNames</code>, and must be manually kept in
sync with the entries in the array. (This was the last of
the classes split off from the original single class;
hence the naming tiredness.)
<br/> <br/>
</dd>
<dt><link href="PropertyConsts.html">PropertyConsts</link></dt>
<dd>
Contains two basic sets of data:<br/>
Property-indexed arrays and property set
definitions.<br/> <br/>
<strong>Property-indexed arrays</strong> are elaborations
of the property indexing idea discussed in relation to the
arrays of property stacks. One of the arrays is<br/> <br/>
<code>public static final LinkedList[]
propertyStacks</code><br/> <br/>
This is an array of stacks, implemented as
<code>LinkedList</code>s, one for each property.<br/> <br/>
The other arrays provide indexed access to fields which
are, in most cases, common to all of the properties. An
exception is<br/> <br/>
<code>public static final Method[]
complexMethods</code><br/> <br/>
which contains a reference to the method
<code>complex()</code> which is only defined for
properties which have complex value parsing requirements.
It is likely that a similar array will be defined for
properties which allow a value of <em>auto</em>.<br/> <br/>
The property-indexed arrays are initialized by
<code>static</code> initializers in this class. The
<code>PropNames</code> class and
<code>Properties</code>
nested classes are scanned in order to obtain or derive
the data necessary for initialization.<br/> <br/>
<strong>Property set definitions</strong> are
<code>HashSet</code>s of properties (represented by
integer constants) which belong to each of the categories
of properties defined. They are used to simplify the
assignment of property sets to individual FOs.
Representative <code>HashSet</code>s include
<em>backgroundProps</em> and
<em>tableProps</em>.<br/> <br/>
</dd>
<dt><link href="Properties.html">Properties</link></dt>
<dd>
<br/>
This class contains only sets of constants for use by the
individual property classes, but it also importantly
serves as a container for all of the property classes, and
some convenience pseudo-property classes.<br/> <br/>
<strong>Constants sets</strong> include:<br/> <br/>
<em>Datatype constants</em>. A bitmap set of
integer constants over a possible range of 2^0 to 2^31
(represented as -2147483648). E.g.<br/>
INTEGER = 1<br/>
ENUM = 524288<br/> <br/>
Some of the definitions are bit-ORed
combinations of the basic values. Used to set the
<em>dataTypes</em> field of the property
classes.<br/> <br/>
<em>Trait mapping constants</em>. A bitmap set of
integer constants over a possible range of 2^0 to 2^31
(represented as -2147483648), representing the manner in
which a property maps into a <em>trait</em>. Used to set
the <code>traitMapping</code> field of the property
classes.<br/> <br/>
<em>Initial value constants</em>. A sequence of
integer constants representing the datatype of the initial
value of a property. Used to set the
<code>initialValueType</code> field of the property
classes.<br/> <br/>
<em>Inheritance value constants</em>. A sequence
of integer constants representing the way in which the
property is normally inherited. Used to set the
<code>inherited</code> field of the property
classes.<br/> <br/>
<strong>Nested property classes</strong>. The
<em>Properties</em> class serves as the holding pen for
all of the individual property classes, and for property
pseudo-classes which contain data common to a number of
actual properties, e.g. <em>ColorCommon</em>.
</dd>
</dl>
</s2>
<p>
<strong>Previous:</strong> <link href=
"alt.properties.html" >alt.properties</link>
</p>
<p>
<strong>Next:</strong> <link href=
"properties-classes.html" >Properties classes</link>
</p>
</s1>
</body>
</document>
1.1 xml-fop/docs/design/alt.design/properties-classes.xml
Index: properties-classes.xml
===================================================================
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- $Id: properties-classes.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ -->
<!--
<!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd">
-->
<document>
<header>
<title>Properties$classes</title>
<authors>
<person name="Peter B. West" email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<!-- one of (anchor s1) -->
<s1 title="fo.Properties and the nested properties classes">
<figure src="PropertyClasses.png" alt="Nested property and
top-level classes"/>
<s2 title="Nested property classes">
<p>
Given the intention that individual properties have only a
<em>virtual</em> instantiation in the arrays of
<code>PropertyConsts</code>, these classes are intended to
remain as repositories of static data and methods. The name
of each property is entered in the
<code>PropNames.propertyNames</code> array of
<code>String</code>s, and each has a unique integer constant
defined, corresponding to the offset of the property name in
that array.
</p>
<s3 title="Fields common to all classes">
<dl>
<dt><code>final int dataTypes</code></dt>
<dd>
This field defines the allowable data types which may be
assigned to the property. The value is chosen from the
data type constants defined in <code>Properties</code>, and
may consist of more than one of those constants,
bit-ORed together.
</dd>
<dt><code>final int traitMapping</code></dt>
<dd>
This field defines the mapping of properties to traits
in the <code>Area tree</code>. The value is chosen from the
trait mapping constants defined in <code>Properties</code>,
and may consist of more than one of those constants,
bit-ORed together.
</dd>
<dt><code>final int initialValueType</code></dt>
<dd>
This field defines the data type of the initial value
assigned to the property. The value is chosen from the
initial value type constants defined in
<code>Properties</code>.
</dd>
<dt><code>final int inherited</code></dt>
<dd>
This field defines the kind of inheritance applicable to
the property. The value is chosen from the inheritance
constants defined in <code>Properties</code>.
</dd>
</dl>
</s3>
<s3 title="Datatype dependent fields">
<dl>
<dt>Enumeration types</dt>
<dd>
<strong><code>final String[] enums</code></strong><br/>
This array contains the <code>NCName</code> text
values of the enumeration. In the current
implementation, it always contains a null value at
<code>enum[0]</code>.<br/> <br/>
<strong><code>final String[]
enumValues</code></strong><br/> When the number of
enumeration values is small,
<code>enumValues</code> is a reference to the
<code>enums</code> array.<br/> <br/>
<strong><code>final HashMap
enumValues</code></strong><br/> When the number of
enumeration values is larger,
<code>enumValues</code> is a
<code>HashMap</code> statically initialized to
contain the integer constant values corresponding to
each text value, indexed by the text
value.<br/> <br/>
<strong><code>final int</code></strong>
<em><code>enumeration-constants</code></em><br/> A
unique integer constant is defined for each of the
possible enumeration values.<br/> <br/>
</dd>
<dt>Many types:
<code>final</code> <em>datatype</em>
<code>initialValue</code></dt>
<dd>
When the initial datatype does not have an implicit
initial value (as, for example, does type
<code>AUTO</code>) the initial value for the property is
assigned to this field. The type of this field will
vary according to the <code>initialValueType</code>
field.
</dd>
<dt>AUTO: <code>PropertyValueList auto(property,
list)></code></dt>
<dd>
When <em>AUTO</em> is a legal value type, the
<code>auto()</code> method must be defined in the property
class.<br/>
<em>NOT YET IMPLEMENTED.</em>
</dd>
<dt>COMPLEX: <code>PropertyValueList complex(property,
list)></code></dt>
<dd>
<em>COMPLEX</em> is specified as a value type when complex
conditions apply to the selection of a value type, or
when lists of values are acceptable. To process and
validate such a property value assignment, the
<code>complex()</code> method must be defined in the
property class.
</dd>
</dl>
</s3>
</s2>
<s2 title="Nested property pseudo-classes">
<p>
The property pseudo-classes are classes, like
<code>ColorCommon</code> which contain values, particularly
<em>enums</em>, which are common to a number of actual
properties.
</p>
</s2>
<p>
<strong>Previous:</strong> <link href= "classes-overview.html"
>property classes overview.</link>
</p>
</s1>
</body>
</document>
1.1 xml-fop/docs/design/alt.design/Properties.png.xml
Index: Properties.png.xml
===================================================================
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- $Id: Properties.png.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ -->
<!--
<!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd">
-->
<document>
<header>
<title>..fo.Properties diagram</title>
<authors>
<person id="pbw" name="Peter B. West"
email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<!-- one of (anchor s1) -->
<s1 title="Properties.class">
<figure src="Properties.png" alt="Properties.class diagram"/>
</s1>
</body>
</document>
1.1 xml-fop/docs/design/alt.design/PropertyConsts.png.xml
Index: PropertyConsts.png.xml
===================================================================
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- $Id: PropertyConsts.png.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ -->
<!--
<!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd">
-->
<document>
<header>
<title>..fo.PropertyConsts diagram</title>
<authors>
<person id="pbw" name="Peter B. West"
email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<!-- one of (anchor s1) -->
<s1 title="PropertyConsts.class">
<figure src="PropertyConsts.png" alt="PropertyConsts.class diagram"/>
</s1>
</body>
</document>
1.1 xml-fop/docs/design/alt.design/propertyExpressions.xml
Index: propertyExpressions.xml
===================================================================
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- $Id: propertyExpressions.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ -->
<!--
<!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd">
-->
<document>
<header>
<title>Property Expression Parsing</title>
<authors>
<person id="pbw" name="Peter B. West" email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<!-- one of (anchor s1) -->
<s1 title="Property expression parsing">
<note>
The following discussion of the experiments with alternate
property expression parsing is very much a work in progress,
and subject to sudden changes.
</note>
<p>
The parsing of property value expressions is handled by two
closely related classes: <code>PropertyTokenizer</code> and its
subclass, <code>PropertyParser</code>.
<code>PropertyTokenizer</code>, as the name suggests, handles
the tokenizing of the expression, handing <em>tokens</em>
back to its subclass,
<code>PropertyParser</code>. <code>PropertyParser</code>, in
turn, returns a <code>PropertyValueList</code>, a list of
<code>PropertyValue</code>s.
</p>
<p>
The tokenizer and parser rely in turn on the datatype
definition from the <code>org.apache.fop.datatypes</code>
package and the datatype <code>static final int</code>
constants from <code>PropertyConsts</code>.
</p>
<s2 title="Data types">
<p>
The data types currently defined in
<code>org.apache.fop.datatypes</code> include:
</p>
<table>
<tr><th colspan="2">Numbers and lengths</th></tr>
<tr>
<th>Numeric</th>
<td colspan="3">
The fundamental numeric data type. <em>Numerics</em> of
various types are constructed by the classes listed
below.
</td>
</tr>
<tr>
<td/>
<th colspan="3">Constructor classes for <em>Numeric</em></th>
</tr>
<tr>
<td/><td>Angle</td>
<td colspan="2">In degrees(deg), gradients(grad) or
radians(rad)</td>
</tr>
<tr>
<td/><td>Ems</td>
<td colspan="2">Relative length in <em>ems</em></td>
</tr>
<tr>
<td/><td>Frequency</td>
<td colspan="2">In hertz(Hz) or kilohertz(kHz)</td>
</tr>
<tr>
<td/><td>IntegerType</td><td/>
</tr>
<tr>
<td/><td>Length</td>
<td colspan="2">In centimetres(cm), millimetres(mm),
inches(in), points(pt), picas(pc) or pixels(px)</td>
</tr>
<tr>
<td/><td>Percentage</td><td/>
</tr>
<tr>
<td/><td>Time</td>
<td>In seconds(s) or milliseconds(ms)</td>
</tr>
<tr><th colspan="2">Strings</th></tr>
<tr>
<th>StringType</th>
<td colspan="3">
Base class for data types which result in a <em>String</em>.
</td>
</tr>
<tr>
<td/><th>Literal</th>
<td colspan="2">
A subclass of <em>StringType</em> for literals which
exceed the constraints of an <em>NCName</em>.
</td>
</tr>
<tr>
<td/><th>MimeType</th>
<td colspan="2">
A subclass of <em>StringType</em> for literals which
represent a mime type.
</td>
</tr>
<tr>
<td/><th>UriType</th>
<td colspan="2">
A subclass of <em>StringType</em> for literals which
represent a URI, as specified by the argument to
<em>url()</em>.
</td>
</tr>
<tr>
<td/><th>NCName</th>
<td colspan="2">
A subclass of <em>StringType</em> for literals which
meet the constraints of an <em>NCName</em>.
</td>
</tr>
<tr>
<td/><td/><th>Country</th>
<td>An RFC 3066/ISO 3166 country code.</td>
</tr>
<tr>
<td/><td/><th>Language</th>
<td>An RFC 3066/ISO 639 language code.</td>
</tr>
<tr>
<td/><td/><th>Script</th>
<td>An ISO 15924 script code.</td>
</tr>
<tr><th colspan="2">Enumerated types</th></tr>
<tr>
<th>EnumType</th>
<td colspan="3">
An integer representing one of the tokens in a set of
enumeration values.
</td>
</tr>
<tr>
<td/><th>MappedEnumType</th>
<td colspan="2">
A subclass of <em>EnumType</em>. Maintains a
<em>String</em> with the value to which the associated
"raw" enumeration token maps. E.g., the
<em>font-size</em> enumeration value "medium" maps to
the <em>String</em> "12pt".
</td>
</tr>
<tr><th colspan="2">Colors</th></tr>
<tr>
<th>ColorType</th>
<td colspan="3">
Maintains a four-element array of float, derived from
the name of a standard colour, the name returned by a
call to <em>system-color()</em>, or an RGB
specification.
</td>
</tr>
<tr><th colspan="2">Fonts</th></tr>
<tr>
<th>FontFamilySet</th>
<td colspan="3">
Maintains an array of <em>String</em>s containing a
prioritized list of possibly generic font family names.
</td>
</tr>
<tr><th colspan="2">Pseudo-types</th></tr>
<tr>
<td colspan="4">
A variety of pseudo-types have been defined as
convenience types for frequently appearing enumeration
token values, or for other special purposes.
</td>
</tr>
<tr>
<th>Inherit</th>
<td colspan="3">
For values of <em>inherit</em>.
</td>
</tr>
<tr>
<th>Auto</th>
<td colspan="3">
For values of <em>auto</em>.
</td>
</tr>
<tr>
<th>None</th>
<td colspan="3">
For values of <em>none</em>.
</td>
</tr>
<tr>
<th>Bool</th>
<td colspan="3">
For values of <em>true/false</em>.
</td>
</tr>
<tr>
<th>FromNearestSpecified</th>
<td colspan="3">
Created to ensure that, when associated with
a shorthand, the <em>from-nearest-specified-value()</em>
core function is the sole component of the expression.
</td>
</tr>
<tr>
<th>FromParent</th>
<td colspan="3">
Created to ensure that, when associated with
a shorthand, the <em>from-parent()</em>
core function is the sole component of the expression.
</td>
</tr>
</table>
</s2>
<s2 title="Tokenizer">
<p>
The tokenizer returns one of the following token
values:
</p>
<source>
static final int
EOF = 0
,NCNAME = 1
,MULTIPLY = 2
,LPAR = 3
,RPAR = 4
,LITERAL = 5
,FUNCTION_LPAR = 6
,PLUS = 7
,MINUS = 8
,MOD = 9
,DIV = 10
,COMMA = 11
,PERCENT = 12
,COLORSPEC = 13
,FLOAT = 14
,INTEGER = 15
,ABSOLUTE_LENGTH = 16
,RELATIVE_LENGTH = 17
,TIME = 18
,FREQ = 19
,ANGLE = 20
,INHERIT = 21
,AUTO = 22
,NONE = 23
,BOOL = 24
,URI = 25
,MIMETYPE = 26
// NO_UNIT is a transient token for internal use only. It is
// never set as the end result of parsing a token.
,NO_UNIT = 27
;
</source>
<p>
Most of these tokens are self-explanatory, but a few need
further comment.
</p>
<dl>
<dt>AUTO</dt>
<dd>
Because of its frequency of occurrence, and the fact that
it is always the <em>initial value</em> for any property
which supports it, AUTO has been promoted into a
pseudo-type with its on datatype class. Therefore, it is
also reported as a token.
</dd>
<dt>NONE</dt>
<dd>
Similarly to AUTO, NONE has been promoted to a pseudo-type
because of its frequency.
</dd>
<dt>BOOL</dt>
<dd>
There is a <em>de facto</em> boolean type buried in the
enumeration types for many of the properties. It had been
specified as a type in its own right in this code.
</dd>
<dt>MIMETYPE</dt>
<dd>
The property <code>content-type</code> introduces this
complication. It can have two values of the form
<strong>content-type:</strong><em>mime-type</em>
(e.g. <code>content-type="content-type:xml/svg"</code>) or
<strong>namespace-prefix:</strong><em>prefix</em>
(e.g. <code>content-type="namespace-prefix:svg"</code>). The
experimental code reduces these options to the payload
in each case: an <code>NCName</code> in the case of a
namespace prefix, and a MIMETYPE in the case of a
content-type specification. <code>NCName</code>s cannot
contain a "/".
</dd>
</dl>
</s2>
<s2 title="Parser">
<p>
The parser retuns a <code>PropertyValueList</code>,
necessary because of the possibility that a list of
<code>PropertyValue</code> elements may be returned from the
expressions of soem properties.
</p>
<p>
<code>PropertyValueList</code>s may contain
<code>PropertyValue</code>s or other
<code>PropertyValueList</code>s. This latter provision is
necessitated for the peculiar case of of
<em>text-shadow</em>, which may contain whitespace separated
sublists of either two or three elements, separated from one
another by commas. To accommodate this peculiarity, comma
separated elements are added to the top-level list, while
whitespace separated values are always collected into
sublists to be added to the top-level list.
</p>
<p>
Other special cases include the processing of the core
functions <code>from-parent()</code> and
<code>from-nearest-specified-value()</code> when these
function calls are assigned to a shorthand property, or used
with a shorthand property name as an argument. In these
cases, the function call must be the sole component of the
expression. The pseudo-element classes
<code>FromParent</code> and
<code>FromNearestSpecified</code> are generated in these
circumstances so that an exception will be thrown if they
are involved in expression evaluation with other
components. (See Rec. Section 5.10.4 Property Value
Functions.)
</p>
<p>
The experimental code is a simple extension of the existing
parser code, which itself borrowed heavily from James
Clark's XT processor.
</p>
</s2>
</s1>
</body>
</document>
1.1 xml-fop/docs/design/alt.design/PropNames.png.xml
Index: PropNames.png.xml
===================================================================
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- $Id: PropNames.png.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ -->
<!--
<!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd">
-->
<document>
<header>
<title>..fo.PropNames diagram</title>
<authors>
<person id="pbw" name="Peter B. West"
email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<!-- one of (anchor s1) -->
<s1 title="PropNames.class">
<figure src="PropNames.png" alt="PropNames.class diagram"/>
</s1>
</body>
</document>
1.1 xml-fop/docs/design/alt.design/VerticalAlign.png.xml
Index: VerticalAlign.png.xml
===================================================================
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- $Id: VerticalAlign.png.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ -->
<!--
<!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd">
-->
<document>
<header>
<title>VerticalAlign diagram</title>
<authors>
<person id="pbw" name="Peter B. West"
email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<!-- one of (anchor s1) -->
<s1 title="Properties$VerticalAlign">
<figure src="VerticalAlign.png" alt="VerticalAlign diagram"/>
</s1>
</body>
</document>
1.1 xml-fop/docs/design/alt.design/xml-parsing.xml
Index: xml-parsing.xml
===================================================================
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- $Id: xml-parsing.xml,v 1.1 2002/03/17 17:24:10 arved Exp $ -->
<!--
<!DOCTYPE document SYSTEM "../xml-docs/dtd/document-v10.dtd">
-->
<document>
<header>
<title>Integrating XML Parsing</title>
<authors>
<person name="Peter B. West" email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<!-- one of (anchor s1) -->
<s1 title="An alternative parser integration">
<p>
This note proposes an alternative method of integrating the
output of the SAX parsing of the Flow Object (FO) tree into
FOP processing. The pupose of the proposed changes is to
provide for better decomposition of the process of analysing
and rendering an fo tree such as is represented in the output
from initial (XSLT) processing of an XML source document.
</p>
<s2 title="Structure of SAX parsing">
<p>
Figure 1 is a schematic representation of the process of SAX
parsing of an input source. SAX parsing involves the
registration, with an object implementing the
<code>XMLReader</code> interface, of a
<code>ContentHandler</code> which contains a callback
routine for each of the event types encountered by the
parser, e.g., <code>startDocument()</code>,
<code>startElement()</code>, <code>characters()</code>,
<code>endElement()</code> and <code>endDocument()</code>.
Parsing is initiated by a call to the <code>parser()</code>
method of the <code>XMLReader</code>. Note that the call to
<code>parser()</code> and the calls to individual callback
methods are synchronous: <code>parser()</code> will only
return when the last callback method returns, and each
callback must complete before the next is called.<br/><br/>
<strong>Figure 1</strong>
</p>
<figure src="SAXParsing.png" alt="SAX parsing schematic"/>
<p>
In the process of parsing, the heirarchical structure of the
original FO tree is flattened into a number of streams of
events of the same type which are reported in the sequence
in which they are encountered. Apart from that, the API
imposes no structure or constraint which expresses the
relationship between, e.g., a startElement event and the
endElement event for the same element. To the extent that
such relationship information is required, it must be
managed by the callback routines.
</p>
<p>
The most direct approach here is to build the tree
"invisibly"; to bury within the callback routines the
necessary code to construct the tree. In the simplest case,
the whole of the FO tree is built within the call to
<code>parser()</code>, and that in-memory tree is subsequently
processed to (a) validate the FO structure, and (b)
construct the Area tree. The problem with this approach is
the potential size of the FO tree in memory. FOP has
suffered from this problem in the past.
</p>
</s2>
<s2 title="Cluttered callbacks">
<p>
On the other hand, the callback code may become increasingly
complex as tree validation and the triggering of the Area
tree processing and subsequent rendering is moved into the
callbacks, typically the <code>endElement()</code> method.
In order to overcome acute memory problems, the FOP code was
recently modified in this way, to trigger Area tree building
and rendering in the <code>endElement()</code> method, when
the end of a page-sequence was detected.
</p>
<p>
The drawback with such a method is that it becomes difficult
to detemine the order of events and the circumstances in
which any particular processing events are triggered. When
the processing events are inherently self-contained, this is
irrelevant. But the more complex and context-dependent the
relationships are among the processing elements, the more
obscurity is engendered in the code by such "side-effect"
processing.
</p>
</s2>
<s2 title="From passive to active parsing">
<p>
In order to solve the simultaneous problems of exposing the
structure of the processing and minimising in-memory
requirements, the experimental code separates the parsing of
the input source from the building of the FO tree and all
downstream processing. The callback routines become
minimal, consisting of the creation and buffering of
<code>XMLEvent</code> objects as a <em>producer</em>. All
of these objects are effectively merged into a single event
stream, in strict event order, for subsequent access by the
FO tree building process, acting as a
<em>consumer</em>. In itself, this does not reduce the
footprint. This occurs when the approach is generalised to
modularise FOP processing.<br/><br/> <strong>Figure 2</strong>
</p>
<figure src="XML-event-buffer.png" alt="XML event buffer"/>
<p>
The most useful change that this brings about is the switch
from <em>passive</em> to <em>active</em> XML element
processing. The process of parsing now becomes visible to
the controlling process. All local validation requirements,
all object and data structure building, is initiated by the
process(es) <em>get</em>ting from the queue - in the case
above, the FO tree builder.
</p>
</s2>
<s2 title="XMLEvent methods">
<anchor id="XMLEvent-methods"/>
<p>
The experimental code uses a class <strong>XMLEvent</strong>
to provide the objects which are placed in the queue.
<em>XMLEvent</em> includes a variety of methods to access
elements in the queue. Namespace URIs encountered in
parsing are maintined in a <code>static</code>
<code>HashMap</code> where they are associated with a unique
integer index. This integer value is used in the signature
of some of the access methods.
</p>
<dl>
<dt>XMLEvent getEvent(SyncedCircularBuffer events)</dt>
<dd>
This is the basis of all of the queue access methods. It
returns the next element from the queue, which may be a
pushback element.
</dd>
<dt>XMLEvent getEndDocument(events)</dt>
<dd>
<em>get</em> and discard elements from the queue
until an ENDDOCUMENT element is found and returned.
</dd>
<dt> XMLEvent expectEndDocument(events)</dt>
<dd>
If the next element on the queue is an ENDDOCUMENT event,
return it. Otherwise, push the element back and throw an
exception. Each of the <em>get</em> methods (except
<em>getEvent()</em> itself) has a corresponding
<em>expect</em> method.
</dd>
<dt>XMLEvent get/expectStartElement(events)</dt>
<dd> Return the next STARTELEMENT event from the queue.</dd>
<dt>XMLEvent get/expectStartElement(events, String
qName)</dt>
<dd>
Return the next STARTELEMENT with a QName matching
<em>qName</em>.
</dd>
<dt>
XMLEvent get/expectStartElement(events, int uriIndex,
String localName)
</dt>
<dd>
Return the next STARTELEMENT with a URI indicated by the
<em>uriIndex</em> and a local name matching <em>localName</em>.
</dd>
<dt>
XMLEvent get/expectStartElement(events, LinkedList list)
</dt>
<dd>
<em>list</em> contains instances of the nested class
<code>UriLocalName</code>, which hold a
<em>uriIndex</em> and a <em>localName</em>. Return
the next STARTELEMENT with a URI indicated by the
<em>uriIndex</em> and a local name matching
<em>localName</em> from any element of
<em>list</em>.
</dd>
<dt>XMLEvent get/expectEndElement(events)</dt>
<dd>Return the next ENDELEMENT.</dd>
<dt>XMLEvent get/expectEndElement(events, qName)</dt>
<dd>Return the next ENDELEMENT with QName
<em>qname</em>.</dd>
<dt>XMLEvent get/expectEndElement(events, uriIndex, localName)</dt>
<dd>
Return the next ENDELEMENT with a URI indicated by the
<em>uriIndex</em> and a local name matching
<em>localName</em>.
</dd>
<dt>
XMLEvent get/expectEndElement(events, XMLEvent event)
</dt>
<dd>
Return the next ENDELEMENT with a URI matching the
<em>uriIndex</em> and <em>localName</em>
matching those in the <em>event</em> argument. This
is intended as a quick way to find the ENDELEMENT matching
a previously returned STARTELEMENT.
</dd>
<dt>XMLEvent get/expectCharacters(events)</dt>
<dd>Return the next CHARACTERS event.</dd>
</dl>
</s2>
<s2 title="FOP modularisation">
<p>
This same principle can be extended to the other major
sub-systems of FOP processing. In each case, while it is
possible to hold a complete intermediate result in memory,
the memory costs of that approach are too high. The
sub-systems - xml parsing, FO tree construction, Area tree
construction and rendering - must run in parallel if the
footprint is to be kept manageable. By creating a series of
producer-consumer pairs linked by synchronized buffers,
logical isolation can be achieved while rates of processing
remain coupled. By introducing feedback loops conveying
information about the completion of processing of the
elements, sub-systems can dispose of or precis those
elements without having to be tightly coupled to downstream
processes.<br/><br/>
<strong>Figure 3</strong>
</p>
<figure src="processPlumbing.png" alt="FOP modularisation"/>
</s2>
</s1>
</body>
</document>
1.1 xml-fop/docs/design/alt.design/dirlist.html
Index: dirlist.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>alt.design</title>
</head>
<body>
<h3>Directory listing of alt.design</h3>
<hr>
<pre><code>
drwxrwxr-x 2 pbw pbw 4096 Jan 31 17:58 .
drwxrwxr-x 5 pbw pbw 4096 Jan 31 17:57 <a
href="../dirlist.html">..</a>
-rw-rw-r-- 1 pbw pbw 949 Jan 25 17:31 <a
href="AbsolutePosition.dia">AbsolutePosition.dia</a>
-rw-rw-r-- 1 pbw pbw 4890 Jan 25 17:31 <a
href="AbsolutePosition.png">AbsolutePosition.png</a>
-rw-r--r-- 1 pbw pbw 579 Jan 25 23:47 <a
href="AbsolutePosition.png.xml">AbsolutePosition.png.xml</a>
-rw-rw-r-- 1 pbw pbw 4140 Jan 25 17:31 <a
href="BorderCommonStyle.png">BorderCommonStyle.png</a>
-rw-r--r-- 1 pbw pbw 584 Jan 26 12:29 <a
href="BorderCommonStyle.png.xml">BorderCommonStyle.png.xml</a>
-rw-rw-r-- 1 pbw pbw 807 Jan 25 17:31 <a
href="PropNames.dia">PropNames.dia</a>
-rw-rw-r-- 1 pbw pbw 3428 Jan 25 17:31 <a
href="PropNames.png">PropNames.png</a>
-rw-r--r-- 1 pbw pbw 551 Jan 25 23:48 <a
href="PropNames.png.xml">PropNames.png.xml</a>
-rw-rw-r-- 1 pbw pbw 1900 Jan 25 17:31 <a
href="Properties.dia">Properties.dia</a>
-rw-rw-r-- 1 pbw pbw 32437 Jan 25 17:31 <a
href="Properties.png">Properties.png</a>
-rw-r--r-- 1 pbw pbw 556 Jan 25 23:48 <a
href="Properties.png.xml">Properties.png.xml</a>
-rw-rw-r-- 1 pbw pbw 2180 Jan 25 17:31 <a
href="PropertyClasses.dia">PropertyClasses.dia</a>
-rw-rw-r-- 1 pbw pbw 17581 Jan 25 17:31 <a
href="PropertyClasses.png">PropertyClasses.png</a>
-rw-rw-r-- 1 pbw pbw 1573 Jan 25 17:31 <a
href="PropertyConsts.dia">PropertyConsts.dia</a>
-rw-rw-r-- 1 pbw pbw 20379 Jan 25 17:31 <a
href="PropertyConsts.png">PropertyConsts.png</a>
-rw-r--r-- 1 pbw pbw 575 Jan 25 23:47 <a
href="PropertyConsts.png.xml">PropertyConsts.png.xml</a>
-rw-rw-r-- 1 pbw pbw 1333 Jan 25 17:31 <a
href="PropertyStaticsOverview.dia">PropertyStaticsOverview.dia</a>
-rw-rw-r-- 1 pbw pbw 7503 Jan 25 17:31 <a
href="PropertyStaticsOverview.png">PropertyStaticsOverview.png</a>
-rw-rw-r-- 1 pbw pbw 3068 Jan 25 17:31 <a
href="SAXParsing.dia">SAXParsing.dia</a>
-rw-rw-r-- 1 pbw pbw 24482 Jan 25 17:31 <a
href="SAXParsing.png">SAXParsing.png</a>
-rw-rw-r-- 1 pbw pbw 964 Jan 25 17:31 <a
href="VerticalAlign.dia">VerticalAlign.dia</a>
-rw-rw-r-- 1 pbw pbw 7091 Jan 25 17:31 <a
href="VerticalAlign.png">VerticalAlign.png</a>
-rw-r--r-- 1 pbw pbw 565 Jan 25 23:48 <a
href="VerticalAlign.png.xml">VerticalAlign.png.xml</a>
-rw-rw-r-- 1 pbw pbw 2004 Jan 25 17:31 <a
href="XML-event-buffer.dia">XML-event-buffer.dia</a>
-rw-rw-r-- 1 pbw pbw 20415 Jan 25 17:31 <a
href="XML-event-buffer.png">XML-event-buffer.png</a>
-rw-rw-r-- 1 pbw pbw 2322 Jan 25 17:31 <a
href="XMLEventQueue.dia">XMLEventQueue.dia</a>
-rw-rw-r-- 1 pbw pbw 11643 Jan 25 17:31 <a
href="XMLEventQueue.png">XMLEventQueue.png</a>
-rw-r--r-- 1 pbw pbw 6584 Jan 26 11:56 <a
href="alt.properties.xml">alt.properties.xml</a>
-rw-rw-r-- 1 pbw pbw 1152 Jan 25 17:31 <a
href="book.xml">book.xml</a>
-rw-r--r-- 1 pbw pbw 7834 Jan 26 13:07 <a
href="classes-overview.xml">classes-overview.xml</a>
-rw-rw-r-- 1 pbw pbw 8330 Jan 25 17:31 <a
href="parserPersistence.png">parserPersistence.png</a>
-rw-rw-r-- 1 pbw pbw 1974 Jan 25 17:31 <a
href="processPlumbing.dia">processPlumbing.dia</a>
-rw-rw-r-- 1 pbw pbw 8689 Jan 25 17:31 <a
href="processPlumbing.png">processPlumbing.png</a>
-rw-r--r-- 1 pbw pbw 5123 Jan 26 11:58 <a
href="properties-classes.xml">properties-classes.xml</a>
-rw-rw-r-- 1 pbw pbw 3115 Jan 25 17:31 <a
href="property-super-classes-full.dia">property-super-classes-full.dia</a>
-rw-rw-r-- 1 pbw pbw 89360 Jan 25 17:31 <a
href="property-super-classes-full.png">property-super-classes-full.png</a>
-rw-r--r-- 1 pbw pbw 10221 Jan 25 23:49 <a
href="propertyExpressions.xml">propertyExpressions.xml</a>
-rw-r--r-- 1 pbw pbw 9361 Jan 26 11:59 <a
href="xml-parsing.xml">xml-parsing.xml</a>
-rw-rw-r-- 1 pbw pbw 2655 Jan 25 17:31 <a
href="xmlevent-queue.dia">xmlevent-queue.dia</a>
-rw-rw-r-- 1 pbw pbw 12326 Jan 25 17:31 <a
href="xmlevent-queue.png">xmlevent-queue.png</a>
</code></pre>
<hr>
</body>
</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
