pbwest 2003/03/12 06:20:15
Added: src/documentation/content/xdocs/design/alt.design/properties
introduction.xml
Log:
Renamed from index.xml
Revision Changes Path
1.1
xml-fop/src/documentation/content/xdocs/design/alt.design/properties/introduction.xml
Index: introduction.xml
===================================================================
<?xml version="1.0" standalone="no"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN"
"http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/document-v11.dtd";>
<document>
<header>
<title>Implementing Properties</title>
<authors>
<person id="pbw" name="Peter B. West" email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<section>
<title>An alternative properties implementation</title>
<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.
</note>
<p>
Property handling is complex and expensive. Varying numbers of
properties <strong>apply</strong> 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>
<section>
<title>The history problem</title>
<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>, <strong>for each applicable
property</strong>, 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>
</section>
<section>
<title>The construction hierarchy</title>
<p>
Properties are resoved in the <strong>FO tree</strong> in a
strictly hierarchical manner. Nodes are detected in the
input in a <strong>pre-order</strong> traversal, and are
built in the same order. This imples that there are two
phases, or states, of property resolution and construction.
Any particular FO node is either in a state of constructing
its own subtree, or in a stable state where the subtree
construction is complete. These states have differenct data
requirements.
</p>
<dl>
<dt>Subtree building</dt>
<dd>
In this state, all properties defined on this node, or any
of its ancestors must be available to the subtree. In
effect, any property defined on this node must be
available to its descendants, as all properties defined on
any ancestor are available to this node.
</dd>
<dt>Stable: subtree building complete</dt>
<dd>
In this state, only the properties <strong>applicable to
this node</strong> need be available.
</dd>
</dl>
</section>
<section>
<title>Representing properties: <property> classes</title>
<section>
<title>Class vs instance</title>
<p>
What information is required of property objects?
More particularly, what information is particular to the
property classes, and what to the instantiated
objects? The answer to this question depend largely on
how the property objects are used in the context
of layout and Area tree construction. The approach taken
in this implementation is that properties are simply flags
on certain data values associated with FOs. The semantics
of these flags are determined within the layout engine.
</p>
<p>
Certain constant information attaches to individual
property classes. This information is detailed in
the descriptions of individual properties in <em>Section
7</em> of the specification. Such information is
represented in <strong>class</strong> fields and data
structures within the classes.
</p>
<p>
The "instance" information content of a property
is:
</p>
<ul>
<li>
explicitly, the <code>PropertyValue</code> datum of
the property, and
</li>
<li>
implicitly, the <strong>Flow Object</strong> to which
the property is attached.
</li>
</ul>
<p>
Properties, then, serve essentially to link <em>FO
instances</em> with <em>PropertyValue instances</em>,
attaching certain invariant semantic markers to the
PropertyValues in the process. In this implementation,
these functions can be realised entirely within the
property <strong>classes</strong> themselves,
without the need to instantiate any objects. In practice,
<strong>property singletons</strong> are
instantiated to make access to some invariants simpler.
</p>
</section>
</section>
<p>
<strong>Next:</strong> <link href="classes-overview.html"
>property classes overview.</link>
</p>
</section>
</body>
</document>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
