You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@xerces.apache.org by an...@apache.org on 2001/07/19 12:09:53 UTC
cvs commit: xml-xerces/java/docs xni.xml
andyc 01/07/19 03:09:53
Modified: java/docs Tag: xerces_j_2 xni.xml
Log:
Added XNI overview documentation. Next, I'll add specific
details about the XNI framework and the Xerces2 implementation.
Revision Changes Path
No revision
No revision
1.1.2.2 +161 -1 xml-xerces/java/docs/Attic/xni.xml
Index: xni.xml
===================================================================
RCS file: /home/cvs/xml-xerces/java/docs/Attic/xni.xml,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- xni.xml 2001/07/19 06:43:10 1.1.2.1
+++ xni.xml 2001/07/19 10:09:53 1.1.2.2
@@ -1,5 +1,165 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE s1 SYSTEM 'dtd/document.dtd'>
<s1 title='Xerces Native Interface'>
- <p><strong>TODO</strong></p>
+ <s2 title='Overview'>
+ <p>
+ The Xerces Native Interface (XNI) is a framework for communicating
+ a "streaming" document information set and constructing generic
+ parser configurations. XNI is part of the Xerces2 development but
+ the Xerces2 parser is just a standards compliant reference
+ implementation of the Xerces Native Interface. Other parsers can be
+ written that conform to XNI without conforming to any particular
+ standards or using any code from the reference implementation.
+ </p>
+ <p>
+ The Xerces Native Interface is used to implement the Xerces2 parser
+ from a set of modular components in a standard configuration. This
+ configuration is then used to drive the DOM and SAX parser
+ implementations provided with Xerces2. However, XNI is merely an
+ <em>internal</em> set of interfaces. There is no need for an XML
+ application programmer to learn XNI if they only intend to interface
+ to the Xerces2 parser using standard interfaces like JAXP, DOM, and
+ SAX. Xerces developers and application developers that need more
+ power and flexibility than that provided by the standard interfaces
+ should read and understand XNI.
+ </p>
+ <p>Overview information:</p>
+ <ul>
+ <li>
+ <jump href='#streaming-info-set'>"Streaming" Information
+ Set</jump>
+ </li>
+ <li>
+ <jump href='#generic-parser-configurations'>Generic Parser
+ Configurations</jump>
+ </li>
+ </ul>
+ <p>Design and implementation information:</p>
+ <ul>
+ <li><link idref='xni-design'>Design Details</link></li>
+ <li><link idref='xni-api'>Application Programming Interface</link></li>
+ <li><link idref='xni-config'>Parser Configuration</link></li>
+ </ul>
+ </s2>
+ <anchor name='streaming-info-set'/>
+ <s2 title='"Streaming" Information Set'>
+ <p>
+ What is meant by a "streaming" information set? Quite simply,
+ the streaming information set is the document information that can
+ be communicated by parsing the document in a serial manner. In
+ other words, it is the information received as-you-see-it. An XNI
+ parser provides this streaming info set to a registered document
+ handler. The XNI document handler is similar to the standard
+ SAX <code>ContentHandler</code> interface but is different in
+ several important ways:
+ </p>
+ <ul>
+ <li>
+ XNI attempts to provide lossless communication of the streaming
+ information set. Therefore, XNI passes the encodings of external
+ parsed entities and other information that is lost when using SAX.
+ </li>
+ <li>
+ The XNI document handler interface is also designed to build a
+ pipeline of parser components where the streaming information set
+ can be fully modified and augmented by each stage in the pipeline.
+ SAX, however, is primarilly a read-only set of interfaces.
+ </li>
+ </ul>
+ <p>
+ The Xerces Native Interface breaks the document's streaming
+ information set into several more manageable interfaces:
+ </p>
+ <table>
+ <tr><th>Interface</th><th>Description</th></tr>
+ <tr>
+ <td><code>XMLDocumentHandler</code></td>
+ <td>Communicates document structure and content information.</td>
+ </tr>
+ <tr>
+ <td><code>XMLDTDHandler</code></td>
+ <td>
+ Communicates basic DTD information such as element and attribute
+ declarations.
+ </td>
+ </tr>
+ <tr>
+ <td><code>XMLDTDContentModelHandler</code></td>
+ <td>
+ Breaks down each element declaration's content model into a
+ set of separate methods so that handlers don't have to reparse
+ the content model string given in the
+ <code>XMLDTDHandler#elementDecl(String,String)</code> method.
+ This separation also helps those applications that want to
+ know boundaries of entities when used as part of an element's
+ content model.
+ </td>
+ </tr>
+ </table>
+ <p>
+ And an additional handler is provided for convenience in defining
+ document fragments:
+ </p>
+ <table>
+ <tr><th>Interface</th><th>Description</th></tr>
+ <tr>
+ <td><code>XMLDocumentFragmentHandler</code></td>
+ <td>Communicates information about a document fragment.</td>
+ </tr>
+ </table>
+ <p>
+ For complete details of the Xerces Native Interface, refer to
+ the <link idref='xni-api'>XNI API</link> documentation.
+ </p>
+ </s2>
+ <anchor name='generic-parser-configurations'/>
+ <s2 title='Generic Parser Configurations'>
+ <p>
+ The Xerces Native Interface document handler interfaces define a
+ document's streaming information set but XNI also contains a set
+ of interfaces that define parser components and configurations.
+ These interfaces provide a framework for a library of parser parts
+ that can be used interchangeably or completely replaced at the
+ programmer's option. This framework allows an unparalleled level
+ of configuration and implementation choices to implement XML
+ applications.
+ </p>
+ <p>
+ The following list details some possible examples of parsers and
+ configurations that can be written using the XNI parser configuration
+ framework:
+ </p>
+ <ul>
+ <li>
+ <strong>HTML Parser</strong><br/>
+ An HTML scanner can be written that breaks an HTML document into
+ a series of XNI callbacks. Using a configuration that swaps the
+ default XML scanner with the HTML scanner, you can create DOM and
+ SAX parsers for HTML documents.
+ </li>
+ <li>
+ <strong>Optimized Parser</strong><br/>
+ For improved XML performance, a minimal XML scanner can be written
+ and swapped for the default, fully compliant XML scanner. In
+ addition, the validator component can be removed from the parser
+ pipeline to reduce the amount of work required to parse XML
+ documents.
+ </li>
+ <li>
+ <strong>XInclude Processor</strong><br/>
+ An XNI parser component can be written to handle XInclude by
+ analyzing the streaming information set and automatically
+ inserting the contents of referenced links into the event stream.
+ By adding this component to the parser pipeline before the
+ validator, included content would appear transparent to the
+ validator as if that content was in the original document.
+ </li>
+ </ul>
+ <p>
+ This is just a small sample of what is possible when using the
+ XNI parser configuration framework. For complete details of the
+ XNI parser configurations, refer to the
+ <link idref='xni-config'>Parser Configuration</link> documentation.
+ </p>
+ </s2>
</s1>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-cvs-help@xml.apache.org