1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
|
<?xml version='1.0' encoding='UTF-8'?>
<!--
* Copyright 2001-2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
-->
<!DOCTYPE s1 SYSTEM 'dtd/document.dtd'>
<s1 title='Xerces Native Interface'>
<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-core'>Core Interfaces</link></li>
<li><link idref='xni-config'>Parser Configuration</link></li>
<li><link idref='xni-xerces2'>Xerces2 Parser Components</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-core'>Core Interfaces</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>
|
