aboutsummaryrefslogtreecommitdiffstats
path: root/docs/design/understanding/xml_parsing.xml
diff options
context:
space:
mode:
authorarved <arved@unknown>2002-03-17 17:24:10 +0000
committerarved <arved@unknown>2002-03-17 17:24:10 +0000
commite817266a9f7d1b0579839cc2383fe988ab5c3bc8 (patch)
tree01977c8281b32489adbee64edf7125fbe47b0245 /docs/design/understanding/xml_parsing.xml
parent63636d3149af05ddc01e8ac38a5d794c36c7af53 (diff)
downloadxmlgraphics-fop-e817266a9f7d1b0579839cc2383fe988ab5c3bc8.tar.gz
xmlgraphics-fop-e817266a9f7d1b0579839cc2383fe988ab5c3bc8.zip
Extra design commentary
git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@194703 13f79535-47bb-0310-9956-ffa450edef68
Diffstat (limited to 'docs/design/understanding/xml_parsing.xml')
-rw-r--r--docs/design/understanding/xml_parsing.xml106
1 files changed, 106 insertions, 0 deletions
diff --git a/docs/design/understanding/xml_parsing.xml b/docs/design/understanding/xml_parsing.xml
new file mode 100644
index 000000000..a7c8d4a85
--- /dev/null
+++ b/docs/design/understanding/xml_parsing.xml
@@ -0,0 +1,106 @@
+<?xml version="1.0"?>
+<document>
+ <header>
+ <title>XML Parsing</title>
+ <subtitle>All you wanted to know about XML Parsing !</subtitle>
+ <authors> <person name="Keiron Liddle" email="keiron@aftexsw.com"/>
+ </authors>
+ </header>
+ <body>
+
+<s1 title="XML Parsing"><p>Since everyone knows the basics we can get
+ into the various stages starting with the XML handling.</p>
+ <s2 title="XML Input"><p>FOP can take the input XML in a number of ways:
+ </p>
+ <ul>
+ <li>SAX Events through SAX Handler
+ <ul>
+ <li>
+ <code>FOTreeBuilder</code> is the SAX Handler which is
+ obtained through <code>getContentHandler</code> on
+ <code>Driver</code>.
+ </li>
+ </ul>
+ </li>
+ <li>
+ DOM which is converted into SAX Events
+ <ul>
+ <li>
+ The conversion of a DOM tree is done via the
+ <code>render(Document)</code> method on
+ <code>Driver</code>.
+ </li>
+ </ul>
+ </li>
+ <li>
+ data source which is parsed and converted into SAX Events
+ <ul>
+ <li>
+ The <code>Driver</code> can take an
+ <code>InputSource</code> as input. This can use a
+ <code>Stream</code>, <code>String</code> etc.
+ </li>
+ </ul>
+ </li>
+ <li>
+ XML+XSLT which is transformed using an XSLT Processor and
+ the result is fired as SAX Events
+ <ul>
+ <li>
+ <code>XSLTInputHandler</code> is used as an
+ <code>InputSource</code> in the
+ render(<code>XMLReader</code>,
+ <code>InputSource</code>) method on
+ <code>Driver</code>
+ </li>
+ </ul>
+ </li>
+ </ul>
+
+ <p>The SAX Events which are fired on the SAX Handler, class
+ <code>FOTreeBuilder</code>, must represent an XSL:FO document. If not there will be an
+ error. Any problems with the XML being well formed are handled here.</p></s2>
+ <s2 title="Element Mappings"><p> The element mapping is a hashmap of all
+ the elements in a particular namespace. This makes it easy to create a
+ different object for each element. Element mappings are static to save on
+ memory. </p><p>To add an extension a developer can put in the classpath a jar
+ that contains the file <code>/META-INF/services/org.apache.fop.fo.ElementMapping</code>.
+ This must contain a line with the fully qualified name of a class that
+ implements the <em>org.apache.fop.fo.ElementMapping</em> interface. This will then be
+ loaded automatically at the start. Internal mappings are: FO, SVG and Extension
+ (pdf bookmarks)</p></s2>
+ <s2 title="Tree Building"><p>The SAX Events will fire all the information
+ for the document with start element, end element, text data etc. This
+ information is used to build up a representation of the FO document. To do this
+ for a namespace there is a set of element mappings. When an element + namepsace
+ mapping is found then it can create an object for that element. If the element
+ is not found then it creates a dummy object or a generic DOM for unknown
+ namespaces.</p>
+ <p>The object is then setup and then given attributes for the element.
+ For the FO Tree the attributes are converted into properties. The FO objects
+ use a property list mapping to convert the attributes into a list of properties
+ for the element. For other XML, for example SVG, a DOM of the XML is
+ constructed. This DOM can then be passed through to the renderer. Other element
+ mappings can be used in different ways, for example to create elements that
+ create areas during the layout process or setup information for the renderer
+ etc.</p>
+ <p>
+ While the tree building is mainly about creating the FO Tree
+ there are some stages that can propagate to the renderer. At
+ the end of a page sequence we know that all pages in the
+ page sequence can be laid out without being effected by any
+ further XML. The significance of this is that the FO Tree
+ for the page sequence may be able to be disposed of. The
+ end of the XML document also tells us that we can finalise
+ the output document. (The layout of individual pages is
+ accomplished by the layout managers page at a time;
+ i.e. they do not need to wait for the end of the page
+ sequence. The page may not yet be complete, however,
+ containing forward page number references, for example.)
+ </p>
+ </s2>
+ <s2 title="Associated Tasks">
+ <ul><li>Error handling for xml not well formed.</li>
+ <li>Error handling for other XML parsing errors.</li><li>Developer
+ info for adding namespace handlers.</li></ul></s2></s1>
+ </body></document> \ No newline at end of file