pbwest 2002/12/26 23:48:56
Modified: src/documentation/content/xdocs/design/alt.design/properties
PropertyConsts-class.xml book.xml index.xml
Log:
WIP
Revision Changes Path
1.2 +3 -3
xml-fop/src/documentation/content/xdocs/design/alt.design/properties/PropertyConsts-class.xml
Index: PropertyConsts-class.xml
===================================================================
RCS file:
/home/cvs/xml-fop/src/documentation/content/xdocs/design/alt.design/properties/PropertyConsts-class.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- PropertyConsts-class.xml 24 Dec 2002 01:25:18 -0000 1.1
+++ PropertyConsts-class.xml 27 Dec 2002 07:48:56 -0000 1.2
@@ -12,11 +12,11 @@
<section>
<title>Introduction</title>
<p>
- <fork href= "../PropertyConsts.html" >This class</fork>, and the
- singleton object which is <fork href=
+ <fork href= "../PropertyConsts.html" >This class</fork>, and
+ the singleton object which is <fork href=
"../PropertyConsts.html#pconsts" >generated by the static
initializer</fork>, is essentially a repository of the static
- data from the <property> classes of
+ data from the property classes of
<code>org.apache.fop.fo.property</code>, and a common point of
access for the methods of those classes.
</p>
1.2 +5 -2
xml-fop/src/documentation/content/xdocs/design/alt.design/properties/book.xml
Index: book.xml
===================================================================
RCS file:
/home/cvs/xml-fop/src/documentation/content/xdocs/design/alt.design/properties/book.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- book.xml 24 Dec 2002 01:25:18 -0000 1.1
+++ book.xml 27 Dec 2002 07:48:56 -0000 1.2
@@ -13,8 +13,11 @@
</menu>
<menu label="Alt properties">
<menu-item label="Introduction" href="index.html"/>
+ <menu-item label="Classes overview" href="classes-overview.html"/>
<menu-item label="PropertyConsts" href="PropertyConsts-class.html"/>
- <menu-item label="Data Handling" href="property-data.html"/>
- <menu-item label="Methods Access" href="property-methods.html"/>
+ <menu-item label="Simple Properties" href="simple-properties.html"/>
+ <menu-item label="getInitialValue" href="getInitialValue.html"/>
+ <menu-item label="Enumerated data" href="enumerated-values.html"/>
+ <menu-item label="Property parsing" href="propertyExpressions.html"/>
</menu>
</book>
1.2 +136 -10
xml-fop/src/documentation/content/xdocs/design/alt.design/properties/index.xml
Index: index.xml
===================================================================
RCS file:
/home/cvs/xml-fop/src/documentation/content/xdocs/design/alt.design/properties/index.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- index.xml 24 Dec 2002 01:25:18 -0000 1.1
+++ index.xml 27 Dec 2002 07:48:56 -0000 1.2
@@ -2,26 +2,152 @@
<!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";>
-<!-- $Id$ -->
-
<document>
<header>
- <title>FOP Alternative Design Properties Notes</title>
- <version>$Revision$ $Name$</version>
+ <title>Implementing Properties</title>
<authors>
- <person name="Peter B. West" email="[EMAIL PROTECTED]"/>
+ <person id="pbw" name="Peter B. West" email="[EMAIL PROTECTED]"/>
</authors>
</header>
-
<body>
<section>
- <title>Alt Design Properties Notes</title>
+ <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>
- This section includes more detailed notes on the classes which
- are involved in the implementation of FO properties.
+ 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]
