--- /dev/null
+<HTML
+><HEAD
+><TITLE
+>What is XML?</TITLE
+><META
+NAME="GENERATOR"
+CONTENT="Modular DocBook HTML Stylesheet Version 1.46"><LINK
+REL="HOME"
+TITLE="The PXP user's guide"
+HREF="index.html"><LINK
+REL="UP"
+TITLE="User's guide"
+HREF="p34.html"><LINK
+REL="PREVIOUS"
+TITLE="User's guide"
+HREF="p34.html"><LINK
+REL="NEXT"
+TITLE="Highlights of XML"
+HREF="x107.html"><LINK
+REL="STYLESHEET"
+TYPE="text/css"
+HREF="markup.css"></HEAD
+><BODY
+CLASS="CHAPTER"
+BGCOLOR="#FFFFFF"
+TEXT="#000000"
+LINK="#0000FF"
+VLINK="#840084"
+ALINK="#0000FF"
+><DIV
+CLASS="NAVHEADER"
+><TABLE
+WIDTH="100%"
+BORDER="0"
+CELLPADDING="0"
+CELLSPACING="0"
+><TR
+><TH
+COLSPAN="3"
+ALIGN="center"
+>The PXP user's guide</TH
+></TR
+><TR
+><TD
+WIDTH="10%"
+ALIGN="left"
+VALIGN="bottom"
+><A
+HREF="p34.html"
+>Prev</A
+></TD
+><TD
+WIDTH="80%"
+ALIGN="center"
+VALIGN="bottom"
+></TD
+><TD
+WIDTH="10%"
+ALIGN="right"
+VALIGN="bottom"
+><A
+HREF="x107.html"
+>Next</A
+></TD
+></TR
+></TABLE
+><HR
+ALIGN="LEFT"
+WIDTH="100%"></DIV
+><DIV
+CLASS="CHAPTER"
+><H1
+><A
+NAME="AEN36"
+>Chapter 1. What is XML?</A
+></H1
+><DIV
+CLASS="TOC"
+><DL
+><DT
+><B
+>Table of Contents</B
+></DT
+><DT
+>1.1. <A
+HREF="c36.html#AEN38"
+>Introduction</A
+></DT
+><DT
+>1.2. <A
+HREF="x107.html"
+>Highlights of XML</A
+></DT
+><DT
+>1.3. <A
+HREF="x468.html"
+>A complete example: The <I
+CLASS="EMPHASIS"
+>readme</I
+> DTD</A
+></DT
+></DL
+></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN38"
+>1.1. Introduction</A
+></H1
+><P
+>XML (short for <I
+CLASS="EMPHASIS"
+>Extensible Markup Language</I
+>)
+generalizes the idea that text documents are typically structured in sections,
+sub-sections, paragraphs, and so on. The format of the document is not fixed
+(as, for example, in HTML), but can be declared by a so-called DTD (document
+type definition). The DTD describes only the rules how the document can be
+structured, but not how the document can be processed. For example, if you want
+to publish a book that uses XML markup, you will need a processor that converts
+the XML file into a printable format such as Postscript. On the one hand, the
+structure of XML documents is configurable; on the other hand, there is no
+longer a canonical interpretation of the elements of the document; for example
+one XML DTD might want that paragraphes are delimited by
+<TT
+CLASS="LITERAL"
+>para</TT
+> tags, and another DTD expects <TT
+CLASS="LITERAL"
+>p</TT
+> tags
+for the same purpose. As a result, for every DTD a new processor is required.</P
+><P
+>Although XML can be used to express structured text documents it is not limited
+to this kind of application. For example, XML can also be used to exchange
+structured data over a network, or to simply store structured data in
+files. Note that XML documents cannot contain arbitrary binary data because
+some characters are forbidden; for some applications you need to encode binary
+data as text (e.g. the base 64 encoding).</P
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="AEN45"
+>1.1.1. The "hello world" example</A
+></H2
+><P
+>The following example shows a very simple DTD, and a corresponding document
+instance. The document is structured such that it consists of sections, and
+that sections consist of paragraphs, and that paragraphs contain plain text:</P
+><PRE
+CLASS="PROGRAMLISTING"
+><!ELEMENT document (section)+>
+<!ELEMENT section (paragraph)+>
+<!ELEMENT paragraph (#PCDATA)></PRE
+><P
+>The following document is an instance of this DTD:</P
+><PRE
+CLASS="PROGRAMLISTING"
+><?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE document SYSTEM "simple.dtd">
+<document>
+ <section>
+ <paragraph>This is a paragraph of the first section.</paragraph>
+ <paragraph>This is another paragraph of the first section.</paragraph>
+ </section>
+ <section>
+ <paragraph>This is the only paragraph of the second section.</paragraph>
+ </section>
+</document></PRE
+><P
+>As in HTML (and, of course, in grand-father SGML), the "pieces" of
+the document are delimited by element braces, i.e. such a piece begins with
+<TT
+CLASS="LITERAL"
+><name-of-the-type-of-the-piece></TT
+> and ends with
+<TT
+CLASS="LITERAL"
+></name-of-the-type-of-the-piece></TT
+>, and the pieces are
+called <I
+CLASS="EMPHASIS"
+>elements</I
+>. Unlike HTML and SGML, both start tags and
+end tags (i.e. the delimiters written in angle brackets) can never be left
+out. For example, HTML calls the paragraphs simply <TT
+CLASS="LITERAL"
+>p</TT
+>, and
+because paragraphs never contain paragraphs, a sequence of several paragraphs
+can be written as:
+
+<PRE
+CLASS="PROGRAMLISTING"
+><p>First paragraph
+<p>Second paragraph</PRE
+>
+
+This is not possible in XML; continuing our example above we must always write
+
+<PRE
+CLASS="PROGRAMLISTING"
+><paragraph>First paragraph</paragraph>
+<paragraph>Second paragraph</paragraph></PRE
+>
+
+The rationale behind that is to (1) simplify the development of XML parsers
+(you need not convert the DTD into a deterministic finite automaton which is
+required to detect omitted tags), and to (2) make it possible to parse the
+document independent of whether the DTD is known or not.</P
+><P
+>The first line of our sample document,
+
+<PRE
+CLASS="PROGRAMLISTING"
+><?xml version="1.0" encoding="ISO-8859-1"?></PRE
+>
+
+is the so-called <I
+CLASS="EMPHASIS"
+>XML declaration</I
+>. It expresses that the
+document follows the conventions of XML version 1.0, and that the document is
+encoded using characters from the ISO-8859-1 character set (often known as
+"Latin 1", mostly used in Western Europe). Although the XML declaration is not
+mandatory, it is good style to include it; everybody sees at the first glance
+that the document uses XML markup and not the similar-looking HTML and SGML
+markup languages. If you omit the XML declaration, the parser will assume
+that the document is encoded as UTF-8 or UTF-16 (there is a rule that makes
+it possible to distinguish between UTF-8 and UTF-16 automatically); these
+are encodings of Unicode's universal character set. (Note that <SPAN
+CLASS="ACRONYM"
+>PXP</SPAN
+>, unlike its
+predecessor "Markup", fully supports Unicode.)</P
+><P
+>The second line,
+
+<PRE
+CLASS="PROGRAMLISTING"
+><!DOCTYPE document SYSTEM "simple.dtd"></PRE
+>
+
+names the DTD that is going to be used for the rest of the document. In
+general, it is possible that the DTD consists of two parts, the so-called
+external and the internal subset. "External" means that the DTD exists as a
+second file; "internal" means that the DTD is included in the same file. In
+this example, there is only an external subset, and the system identifier
+"simple.dtd" specifies where the DTD file can be found. System identifiers are
+interpreted as URLs; for instance this would be legal:
+
+<PRE
+CLASS="PROGRAMLISTING"
+><!DOCTYPE document SYSTEM "http://host/location/simple.dtd"></PRE
+>
+
+Please note that <SPAN
+CLASS="ACRONYM"
+>PXP</SPAN
+> cannot interpret HTTP identifiers by default, but it is
+possible to change the interpretation of system identifiers.</P
+><P
+>The word immediately following <TT
+CLASS="LITERAL"
+>DOCTYPE</TT
+> determines which of
+the declared element types (here "document", "section", and "paragraph") is
+used for the outermost element, the <I
+CLASS="EMPHASIS"
+>root element</I
+>. In this
+example it is <TT
+CLASS="LITERAL"
+>document</TT
+> because the outermost element is
+delimited by <TT
+CLASS="LITERAL"
+><document></TT
+> and
+<TT
+CLASS="LITERAL"
+></document></TT
+>. </P
+><P
+>The DTD consists of three declarations for element types:
+<TT
+CLASS="LITERAL"
+>document</TT
+>, <TT
+CLASS="LITERAL"
+>section</TT
+>, and
+<TT
+CLASS="LITERAL"
+>paragraph</TT
+>. Such a declaration has two parts:
+
+<PRE
+CLASS="PROGRAMLISTING"
+><!ELEMENT <TT
+CLASS="REPLACEABLE"
+><I
+>name</I
+></TT
+> <TT
+CLASS="REPLACEABLE"
+><I
+>content-model</I
+></TT
+>></PRE
+>
+
+The content model is a regular expression which describes the possible inner
+structure of the element. Here, <TT
+CLASS="LITERAL"
+>document</TT
+> contains one or
+more sections, and a <TT
+CLASS="LITERAL"
+>section</TT
+> contains one or more
+paragraphs. Note that these two element types are not allowed to contain
+arbitrary text. Only the <TT
+CLASS="LITERAL"
+>paragraph</TT
+> element type is declared
+such that parsed character data (indicated by the symbol
+<TT
+CLASS="LITERAL"
+>#PCDATA</TT
+>) is permitted.</P
+><P
+>See below for a detailed discussion of content models. </P
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="AEN84"
+>1.1.2. XML parsers and processors</A
+></H2
+><P
+>XML documents are human-readable, but this is not the main purpose of this
+language. XML has been designed such that documents can be read by a program
+called an <I
+CLASS="EMPHASIS"
+>XML parser</I
+>. The parser checks that the document
+is well-formatted, and it represents the document as objects of the programming
+language. There are two aspects when checking the document: First, the document
+must follow some basic syntactic rules, such as that tags are written in angle
+brackets, that for every start tag there must be a corresponding end tag and so
+on. A document respecting these rules is
+<I
+CLASS="EMPHASIS"
+>well-formed</I
+>. Second, the document must match the DTD in
+which case the document is <I
+CLASS="EMPHASIS"
+>valid</I
+>. Many parsers check only
+on well-formedness and ignore the DTD; <SPAN
+CLASS="ACRONYM"
+>PXP</SPAN
+> is designed such that it can
+even validate the document.</P
+><P
+>A parser does not make a sensible application, it only reads XML
+documents. The whole application working with XML-formatted data is called an
+<I
+CLASS="EMPHASIS"
+>XML processor</I
+>. Often XML processors convert documents into
+another format, such as HTML or Postscript. Sometimes processors extract data
+of the documents and output the processed data again XML-formatted. The parser
+can help the application processing the document; for example it can provide
+means to access the document in a specific manner. <SPAN
+CLASS="ACRONYM"
+>PXP</SPAN
+> supports an
+object-oriented access layer specially.</P
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="AEN94"
+>1.1.3. Discussion</A
+></H2
+><P
+>As we have seen, there are two levels of description: On the one hand, XML can
+define rules about the format of a document (the DTD), on the other hand, XML
+expresses structured documents. There are a number of possible applications:</P
+><P
+></P
+><UL
+COMPACT="COMPACT"
+><LI
+STYLE="list-style-type: disc"
+><P
+>XML can be used to express structured texts. Unlike HTML, there is no canonical
+interpretation; one would have to write a backend for the DTD that translates
+the structured texts into a format that existing browsers, printers
+etc. understand. The advantage of a self-defined document format is that it is
+possible to design the format in a more problem-oriented way. For example, if
+the task is to extract reports from a database, one can use a DTD that reflects
+the structure of the report or the database. A possible approach would be to
+have an element type for every database table and for every column. Once the
+DTD has been designed, the report procedure can be splitted up in a part that
+selects the database rows and outputs them as an XML document according to the
+DTD, and in a part that translates the document into other formats. Of course,
+the latter part can be solved in a generic way, e.g. there may be configurable
+backends for all DTDs that follow the approach and have element types for
+tables and columns.</P
+><P
+>XML plays the role of a configurable intermediate format. The database
+extraction function can be written without having to know the details of
+typesetting; the backends can be written without having to know the details of
+the database.</P
+><P
+>Of course, there are traditional solutions. One can define an ad hoc
+intermediate text file format. This disadvantage is that there are no names for
+the pieces of the format, and that such formats usually lack of documentation
+because of this. Another solution would be to have a binary representation,
+either as language-dependent or language-independent structure (example of the
+latter can be found in RPC implementations). The disadvantage is that it is
+harder to view such representations, one has to write pretty printers for this
+purpose. It is also more difficult to enter test data; XML is plain text that
+can be written using an arbitrary editor (Emacs has even a good XML mode,
+PSGML). All these alternatives suffer from a missing structure checker,
+i.e. the programs processing these formats usually do not check the input file
+or input object in detail; XML parsers check the syntax of the input (the
+so-called well-formedness check), and the advanced parsers like <SPAN
+CLASS="ACRONYM"
+>PXP</SPAN
+> even
+verify that the structure matches the DTD (the so-called validation).</P
+></LI
+><LI
+STYLE="list-style-type: disc"
+><P
+>XML can be used as configurable communication language. A fundamental problem
+of every communication is that sender and receiver must follow the same
+conventions about the language. For data exchange, the question is usually
+which data records and fields are available, how they are syntactically
+composed, and which values are possible for the various fields. Similar
+questions arise for text document exchange. XML does not answer these problems
+completely, but it reduces the number of ambiguities for such conventions: The
+outlines of the syntax are specified by the DTD (but not necessarily the
+details), and XML introduces canonical names for the components of documents
+such that it is simpler to describe the rest of the syntax and the semantics
+informally.</P
+></LI
+><LI
+STYLE="list-style-type: disc"
+><P
+>XML is a data storage format. Currently, every software product tends to use
+its own way to store data; commercial software often does not describe such
+formats, and it is a pain to integrate such software into a bigger project.
+XML can help to improve this situation when several applications share the same
+syntax of data files. DTDs are then neutral instances that check the format of
+data files independent of applications. </P
+></LI
+></UL
+></DIV
+></DIV
+></DIV
+><DIV
+CLASS="NAVFOOTER"
+><HR
+ALIGN="LEFT"
+WIDTH="100%"><TABLE
+WIDTH="100%"
+BORDER="0"
+CELLPADDING="0"
+CELLSPACING="0"
+><TR
+><TD
+WIDTH="33%"
+ALIGN="left"
+VALIGN="top"
+><A
+HREF="p34.html"
+>Prev</A
+></TD
+><TD
+WIDTH="34%"
+ALIGN="center"
+VALIGN="top"
+><A
+HREF="index.html"
+>Home</A
+></TD
+><TD
+WIDTH="33%"
+ALIGN="right"
+VALIGN="top"
+><A
+HREF="x107.html"
+>Next</A
+></TD
+></TR
+><TR
+><TD
+WIDTH="33%"
+ALIGN="left"
+VALIGN="top"
+>User's guide</TD
+><TD
+WIDTH="34%"
+ALIGN="center"
+VALIGN="top"
+><A
+HREF="p34.html"
+>Up</A
+></TD
+><TD
+WIDTH="33%"
+ALIGN="right"
+VALIGN="top"
+>Highlights of XML</TD
+></TR
+></TABLE
+></DIV
+></BODY
+></HTML
+>
\ No newline at end of file
projects / helm.git / blobdiff