<tdvalign="top">Reports events related to the lexical structure of the
document (the beginning of the DTD, comments etc.).
</table></center>
<p> These classes are abstract classes describing the interface. The <ahref="qxmldefaulthandler.html">TQXmlDefaultHandler</a> class provides a "do nothing" default
implementation for all of them. Therefore users only need to overload
the <ahref="qxmldefaulthandler.html">TQXmlDefaultHandler</a> functions they are interested in.
<p> To read input XML data a special class <ahref="qxmlinputsource.html">TQXmlInputSource</a> is used.
<p> Apart from those already mentioned, the following SAX2 support classes
A reader that does not support the <em>http://xml.org/sax/features/namespace-prefixes</em> feature would report
the element name <em>document</em> but not its attributes <em>xmlns:book</em> and
<em>xmlns</em> with their values. A reader with the feature <em>http://xml.org/sax/features/namespace-prefixes</em> reports the namespace
attributes if the <ahref="qxmlreader.html#feature">feature</a> is
switched on.
<p> Other features include <em>http://xml.org/sax/features/namespace</em>
(namespace processing, implies <em>http://xml.org/sax/features/namespace-prefixes</em>) and <em>http://xml.org/sax/features/validation</em> (the ability to report
validation errors).
<p> Whilst SAX2 leaves it to the user to define and implement whatever
features are required, support for <em>http://xml.org/sax/features/namespace</em> (and thus <em>http://xml.org/sax/features/namespace-prefixes</em>) is mandantory.
<p> They influence the reporting behavior in the following way:
<oltype=1>
<li> Namespace prefixes and local parts of elements and attributes can
be reported.
<li> The qualified names of elements and attributes are reported.
<li><ahref="qxmlcontenthandler.html#startPrefixMapping">TQXmlContentHandler::startPrefixMapping</a>() and <ahref="qxmlcontenthandler.html#endPrefixMapping">TQXmlContentHandler::endPrefixMapping</a>() are called by the reader.
<li> Attributes that declare namespaces (i.e. the attribute <em>xmlns</em> and
attributes starting with <em>xmlns:</em>) are reported.
With <em>http://xml.org/sax/features/namespace-prefixes</em> set to TRUE
the reader will report four attributes; but with the <em>namespace-prefixes</em> feature set to FALSE only three, with the <em>xmlns:fnord</em> attribute defining a namespace being "invisible" to the
reader.
<p> The <em>http://xml.org/sax/features/namespaces</em> feature is responsible
for reporting local names, namespace prefixes and URIs. With <em>http://xml.org/sax/features/namespaces</em> set to TRUE the parser will
report <em>title</em> as the local name of the <em>fnord:title</em> attribute, <em>fnord</em> being the namespace prefix and <em>http://trolltech.com/fnord/</em> as
the namespace URI. When <em>http://xml.org/sax/features/namespaces</em> is
FALSE none of them are reported.
<p> In the current implementation the TQt XML classes follow the definition
that the prefix <em>xmlns</em> itself isn't associated with any namespace at all
(see <ahref="http://www.w3.org/TR/1999/REC-xml-names-19990114/#ns-using">http://www.w3.org/TR/1999/REC-xml-names-19990114/#ns-using</a>).
Therefore even with <em>http://xml.org/sax/features/namespaces</em> and
<em>http://xml.org/sax/features/namespace-prefixes</em> both set to TRUE
the reader won't return either a local name, a namespace prefix or
a namespace URI for <em>xmlns:fnord</em>.
<p> This might be changed in the future following the W3C suggestion
<p> Anyone can define and use new SAX2 properties for their readers.
Property support is not mandatory.
<p> To set or query properties the following functions are provided: <ahref="qxmlreader.html#setProperty">TQXmlReader::setProperty</a>(), <ahref="qxmlreader.html#property">TQXmlReader::property</a>() and <ahref="qxmlreader.html#hasProperty">TQXmlReader::hasProperty</a>().
<p><aname="sax2Reading"></a>
<h3> Further reading
</h3>
<aname="2-5"></a><p> More information about XML (e.g. <ahref="xml.html#namespaces">namespaces</a>)
can be found in the <ahref="xml.html">introduction to the TQt XML module.</a>
<p><aname="dom"></a>
<h2> The TQt DOM classes
</h2>
<aname="3"></a><p><aname="domIntro"></a>
<h3> Introduction to DOM
</h3>
<aname="3-1"></a><p> DOM provides an interface to access and change the content and
structure of an XML file. It makes a hierarchical view of the document
(a tree view). Thus -- in contrast to the SAX2 interface -- an object
model of the document is resident in memory after parsing which makes
manipulation easy.
<p> All DOM nodes in the document tree are subclasses of <ahref="qdomnode.html">TQDomNode</a>. The
document itself is represented as a <ahref="qdomdocument.html">TQDomDocument</a> object.
<p> Here are the available node classes and their potential child classes:
<p><ul>
<li><ahref="qdomdocument.html">TQDomDocument</a>: Possible children are
<ul>
<li><ahref="qdomelement.html">TQDomElement</a> (at most one)
<li><ahref="qdomnotation.html">TQDomNotation</a>: No children
</ul>
<p> With <ahref="qdomnodelist.html">TQDomNodeList</a> and <ahref="qdomnamednodemap.html">TQDomNamedNodeMap</a> two <ahref="collection.html#collection-classes">collection classes</a>
are provided: <ahref="qdomnodelist.html">TQDomNodeList</a> is a list of nodes,
and <ahref="qdomnamednodemap.html">TQDomNamedNodeMap</a> is used to handle unordered sets of nodes
(often used for attributes).
<p> The <ahref="qdomimplementation.html">TQDomImplementation</a> class allows the user to query features of the
DOM implementation.
<p><h3> Further reading
</h3>
<aname="3-2"></a><p> To get started please refer to the <ahref="qdomdocument.html">TQDomDocument</a> documentation.
<p><aname="namespaces"></a>
<h2> An introduction to namespaces
</h2>
<aname="4"></a><p> Parts of the TQt XML module documentation assume that you are familiar
with XML namespaces. Here we present a brief introduction; skip to
<ahref="#namespacesConventions">TQt XML documentation conventions</a>
if you already know this material.
<p> Namespaces are a concept introduced into XML to allow a more modular
design. With their help data processing software can easily resolve
naming conflicts in XML documents.
<p> Consider the following example:
<p><pre>
<document>
<book>
<title>Practical XML</title>
<author title="Ms" name="Eris Kallisti"/>
<chapter>
<title>A Namespace Called fnord</title>
</chapter>
</book>
</document>
</pre>
<p> Here we find three different uses of the name <em>title</em>. If you wish to
process this document you will encounter problems because each of the
<em>titles</em> should be displayed in a different manner -- even though
they have the same name.
<p> The solution would be to have some means of identifying the first
occurrence of <em>title</em> as the title of a book, i.e. to use the <em>title</em> element of a book namespace to distinguish it from, for example,
<title>A Namespace Called fnord</title>
</chapter>
</book>
</document>
</pre>
<p> Within the <em>document</em> element we have two namespaces declared. The
default namespace <em>http://trolltech.com/fnord/</em> applies to the <em>book</em> element, the <em>chapter</em> element, the appropriate <em>title</em> element
and of course to <em>document</em> itself.
<p> The <em>book:author</em> and <em>book:title</em> elements belong to the namespace
with the URI <em>http://trolltech.com/fnord/book/</em>.
<p> The two <em>book:author</em> attributes <em>title</em> and <em>name</em> have no XML
namespace assigned. They are only members of the "traditional"
namespace of the element <em>book:author</em>, meaning that for example two
<em>title</em> attributes in <em>book:author</em> are forbidden.
<p> In the above example we circumvent the last rule by adding a <em>title</em>
attribute from the <em>http://trolltech.com/fnord/</em> namespace to <em>book:author</em>: the <em>fnord:title</em> comes from the namespace with the
prefix <em>fnord</em> that is declared in the <em>book:author</em> element.
<p> Clearly the <em>fnord</em> namespace has the same namespace URI as the
default namespace. So why didn't we simply use the default namespace
