From owner-svn-doc-head@FreeBSD.ORG Fri Jul 12 04:33:44 2013 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5C73F4A9; Fri, 12 Jul 2013 04:33:44 +0000 (UTC) (envelope-from wblock@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id 4DD4018F8; Fri, 12 Jul 2013 04:33:44 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r6C4XixV055698; Fri, 12 Jul 2013 04:33:44 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id r6C4XilV055697; Fri, 12 Jul 2013 04:33:44 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201307120433.r6C4XilV055697@svn.freebsd.org> From: Warren Block Date: Fri, 12 Jul 2013 04:33:44 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r42260 - head/en_US.ISO8859-1/books/fdp-primer/xml-primer X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 04:33:44 -0000 Author: wblock Date: Fri Jul 12 04:33:43 2013 New Revision: 42260 URL: http://svnweb.freebsd.org/changeset/doc/42260 Log: Whitespace-only fixes. Translators, please ignore. Modified: head/en_US.ISO8859-1/books/fdp-primer/xml-primer/chapter.xml Modified: head/en_US.ISO8859-1/books/fdp-primer/xml-primer/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/fdp-primer/xml-primer/chapter.xml Fri Jul 12 04:05:39 2013 (r42259) +++ head/en_US.ISO8859-1/books/fdp-primer/xml-primer/chapter.xml Fri Jul 12 04:33:43 2013 (r42260) @@ -35,8 +35,8 @@ XML Primer Most FDP documentation is written with markup languages based - on XML. This chapter explains what that means, how to - read and understand the documentation source, and the + on XML. This chapter explains what that means, + how to read and understand the documentation source, and the XML techniques used. Portions of this section were inspired by Mark Galassi's @@ -47,27 +47,27 @@ Overview - In the original days of computers, electronic text was simple. - - There were a few character sets like ASCII or EBCDIC, but - that was about it. Text was text, and what you saw really was - what you got. No frills, no formatting, no intelligence. + In the original days of computers, electronic text was + simple. There were a few character sets like + ASCII or EBCDIC, but that + was about it. Text was text, and what you saw really was what + you got. No frills, no formatting, no intelligence. Inevitably, this was not enough. When text is in a machine-usable format, machines are expected to be able to use - and manipulate it intelligently. Authors want to indicate - that certain phrases should be emphasized, or added to a - glossary, or made into hyperlinks. Filenames could be - shown in a typewriter style font for viewing on - screen, but as italics when printed, or any of a - myriad of other options for presentation. + and manipulate it intelligently. Authors want to indicate that + certain phrases should be emphasized, or added to a glossary, or + made into hyperlinks. Filenames could be shown in a + typewriter style font for viewing on screen, but + as italics when printed, or any of a myriad of + other options for presentation. It was once hoped that Artificial Intelligence (AI) would make this easy. The computer would read the document and automatically identify key phrases, filenames, text that the reader should type in, examples, and more. Unfortunately, real - life has not happened quite like that, and computers still require - assistance before they can meaningfully process + life has not happened quite like that, and computers still + require assistance before they can meaningfully process text. More precisely, they need help identifying what is what. @@ -95,13 +95,14 @@ the markup from the user, so the user is not distracted by it. - The extra information stored in the markup adds - value to the document. Adding the markup to the - document must typically be done by a person—after all, if - computers could recognize the text sufficiently well to add the - markup then there would be no need to add it in the first place. - This increases the cost (the effort - required) to create the document. + The extra information stored in the markup + adds value to the document. Adding the + markup to the document must typically be done by a + person—after all, if computers could recognize the text + sufficiently well to add the markup then there would be no need + to add it in the first place. This + increases the cost (the effort required) to + create the document. The previous example is actually represented in this document like this: @@ -110,79 +111,83 @@ screen&prompt.user; userinputrm /tmp/foouserinputscreen - The markup is clearly separate from the - content. + The markup is clearly separate from the content. - Markup languages define - what the markup means and how it should be interpreted. + Markup languages define what the markup means and how it + should be interpreted. Of course, one markup language might not be enough. A markup language for technical documentation has very different - requirements than a markup language that is intended for - cookery recipes. This, in turn, would be very different from a - markup language used to describe poetry. What is really needed - is a first language used to write these other markup - languages. A meta markup language. + requirements than a markup language that is intended for cookery + recipes. This, in turn, would be very different from a markup + language used to describe poetry. What is really needed is a + first language used to write these other markup languages. A + meta markup language. This is exactly what the eXtensible Markup - Language (XML) is. Many markup languages have been written in - XML, including the two most used by the FDP, XHTML and - DocBook. + Language (XML) is. Many markup languages + have been written in XML, including the two + most used by the FDP, + XHTML and DocBook. Each language definition is more properly called a grammar, - vocabulary, schema or Document Type Definition (DTD). There - are various languages to specify an XML grammar, for example, - DTD (yes, it also means the specification language itself), - XML Schema (XSD) or RELANG NG. The schema specifies the name - of the elements that can be used, what order they appear in (and - whether some markup can be used inside other markup) and related - information. + vocabulary, schema or Document Type Definition + (DTD). There are various languages to + specify an XML grammar, for example, + DTD (yes, it also means the specification + language itself), XML Schema + (XSD) or RELANG NG. The + schema specifies the name of the elements that can be used, what + order they appear in (and whether some markup can be used inside + other markup) and related information. A schema is a complete specification of all the elements that are allowed to appear, the order in which they should appear, which elements are mandatory, which are optional, and so - forth. This makes it possible to write an XML - parser which reads in both the schema and a - document which claims to conform to the schema. The parser can - then confirm whether or not all the elements required by the vocabulary - are in the document in the right order, and whether there are - any errors in the markup. This is normally referred to as + forth. This makes it possible to write an + XML parser which reads + in both the schema and a document which claims to conform to the + schema. The parser can then confirm whether or not all the + elements required by the vocabulary are in the document in the + right order, and whether there are any errors in the markup. + This is normally referred to as validating the document. This processing simply confirms that the choice of elements, their ordering, and so on, conforms to that listed - in the grammar. It does not check whether - appropriate markup has been used for the - content. If all the filenames in a - document were marked up as function names, the parser would not flag this as - an error (assuming, of course, that the schema defines elements - for filenames and functions, and that they are allowed to - appear in the same place). + in the grammar. It does not check + whether appropriate markup has been used + for the content. If all the filenames in a document were + marked up as function names, the parser would not flag this as + an error (assuming, of course, that the schema defines + elements for filenames and functions, and that they are + allowed to appear in the same place). - It is likely that most contributions to the - Documentation Project will be content marked up in - either XHTML or DocBook, rather than alterations to the schemas. - For this reason, this book will not touch on how to write a - vocabulary. + It is likely that most contributions to the Documentation + Project will be content marked up in either + XHTML or DocBook, rather than alterations to + the schemas. For this reason, this book will not touch on how + to write a vocabulary. Elements, Tags, and Attributes - All the vocabularies written in XML share certain characteristics. - This is hardly surprising, as the philosophy behind XML will - inevitably show through. One of the most obvious manifestations - of this philosophy is that of content and + All the vocabularies written in XML share + certain characteristics. This is hardly surprising, as the + philosophy behind XML will inevitably show + through. One of the most obvious manifestations of this + philosophy is that of content and elements. - Documentation, whether it is a single web page, or a - lengthy book, is considered to consist of content. This content - is then divided and further subdivided into elements. The - purpose of adding markup is to name and identify the boundaries - of these elements for further processing. + Documentation, whether it is a single web page, or a lengthy + book, is considered to consist of content. This content is then + divided and further subdivided into elements. The purpose of + adding markup is to name and identify the boundaries of these + elements for further processing. For example, consider a typical book. At the very top level, the book is itself an element. This book @@ -193,44 +198,45 @@ that was direct speech, or the name of a character in the story. - It may be helpful to think of this as chunking - content. At the very top level is one chunk, the book. - Look a little deeper, and there are more chunks, the individual - chapters. These are chunked further into paragraphs, footnotes, - character names, and so on. - - Notice how this differentiation between - different elements of the content can be made without resorting to any XML - terms. It really is surprisingly straightforward. This could be done - with a highlighter pen and a printout of the book, using - different colors to indicate different chunks of content. + It may be helpful to think of this as + chunking content. At the very top level is one + chunk, the book. Look a little deeper, and there are more + chunks, the individual chapters. These are chunked further into + paragraphs, footnotes, character names, and so on. + + Notice how this differentiation between different elements + of the content can be made without resorting to any + XML terms. It really is surprisingly + straightforward. This could be done with a highlighter pen and + a printout of the book, using different colors to indicate + different chunks of content. Of course, we do not have an electronic highlighter pen, so we need some other way of indicating which element each piece of - content belongs to. In languages written in XML (XHTML, - DocBook, et al) this is done by means of - tags. + content belongs to. In languages written in + XML (XHTML, DocBook, et + al) this is done by means of tags. A tag is used to identify where a particular element starts, and where the element ends. The tag is not part of - the element itself. Because each grammar was normally - written to mark up specific types of information, each one will - recognize different elements, and will therefore have different - names for the tags. + the element itself. Because each grammar was + normally written to mark up specific types of information, each + one will recognize different elements, and will therefore have + different names for the tags. For an element called element-name the start tag will - normally look like - element-name. The - corresponding closing tag for this element is - element-name. + normally look like element-name. + The corresponding closing tag for this element is element-name. Using an Element (Start and End Tags) - XHTML has an element for indicating that the content - enclosed by the element is a paragraph, called - p. + XHTML has an element for indicating + that the content enclosed by the element is a paragraph, + called p. pThis is a paragraph. It starts with the start tag for the 'p' element, and it will end with the end tag for the 'p' @@ -239,19 +245,18 @@ pThis is another paragraph. But this one is much shorter.p - Some elements have no - content. For example, in XHTML, a - horizontal line can be included in the document. - For these empty elements, XML introduced - a shorthand form that is completely equivalent to the two-tag - version: + Some elements have no content. For example, in + XHTML, a horizontal line can be included in + the document. For these empty elements, + XML introduced a shorthand form that is + completely equivalent to the two-tag version: Using an Element Without Content - XHTML has an element for indicating a horizontal rule, - called hr. This element does not wrap - content, so it looks like this: + XHTML has an element for indicating a + horizontal rule, called hr. This element + does not wrap content, so it looks like this: pOne paragraph.p hrhr @@ -268,10 +273,10 @@ from the previous paragraph.p - As shown above, elements can contain other - elements. In the book example earlier, the book element - contained all the chapter elements, which in turn contained all - the paragraph elements, and so on. + As shown above, elements can contain other elements. In the + book example earlier, the book element contained all the chapter + elements, which in turn contained all the paragraph elements, + and so on. Elements Within Elements; <sgmltag>em</sgmltag> @@ -280,8 +285,8 @@ of the emwordsem have been ememphasizedem.p - The grammar consists of rules that describe which elements can - contain other elements, and exactly what they can + The grammar consists of rules that describe which elements + can contain other elements, and exactly what they can contain. @@ -294,12 +299,13 @@ element starts and ends. When this document (or anyone else knowledgeable about - XML) refers to the p tag + XML) refers to + the p tag they mean the literal text consisting of the three characters <, p, and - >. But the phrase the - p element refers to the whole - element. + >. But the phrase + the p element refers to the + whole element. This distinction is very subtle. But keep it in mind. @@ -316,14 +322,14 @@ take the form attribute-name="attribute-value". - In XHTML, the - p element has an attribute called - align, which suggests an alignment - (justification) for the paragraph to the program displaying the - XHTML. + In XHTML, the p + element has an attribute called + align, which suggests an + alignment (justification) for the paragraph to the program + displaying the XHTML. - The align attribute can take one of four - defined values, left, + The align attribute can + take one of four defined values, left, center, right and justify. If the attribute is not specified then the default is left. @@ -349,8 +355,8 @@ Attribute values in XML must be enclosed in either single or double quotes. Double quotes are - traditional. Single quotes are useful when the attribute - value contains double quotes. + traditional. Single quotes are useful when the attribute value + contains double quotes. Information about attributes, elements, and tags is stored in catalog files. The Documentation Project uses standard @@ -371,17 +377,17 @@ Install textproc/docproj from the &os; Ports Collection. This is a - meta-port that downloads and - installs the standard programs and supporting files needed - by the Documentation Project. + meta-port that downloads and installs + the standard programs and supporting files needed by the + Documentation Project. Add lines to the shell startup files to set - SGML_CATALOG_FILES. When working on non-English - versions of the documentation, replace - en_US.ISO8859-1 with the appropriate directory for the - target language. + SGML_CATALOG_FILES. When working on + non-English versions of the documentation, replace + en_US.ISO8859-1 with the + appropriate directory for the target language. <filename>.profile</filename>, for &man.sh.1; and @@ -410,9 +416,9 @@ setenv SGML_CATALOG_FILES /usr/doc/share setenv SGML_CATALOG_FILES /usr/doc/<replaceable>en_US.ISO8859-1</replaceable>/share/xml/catalog:$SGML_CATALOG_FILES</programlisting> </example> - <para>After making these changes, either log out and log back in again, or run - the commands from the command line to set the variable - values.</para> + <para>After making these changes, either log out and log + back in again, or run the commands from the command line + to set the variable values.</para> </step> </procedure> @@ -439,41 +445,44 @@ setenv SGML_CATALOG_FILES /usr/doc/<repl </step> <step> - <para>Try to validate this file using an <acronym>XML</acronym> parser.</para> + <para>Try to validate this file using an + <acronym>XML</acronym> parser.</para> - <para><filename role="package">textproc/docproj</filename> includes - the <command>xmllint</command> + <para><filename role="package">textproc/docproj</filename> + includes the <command>xmllint</command> <link linkend="xml-primer-validating">validating parser</link>.</para> - <para>Use <command>xmllint</command> to - validate the document:</para> + <para>Use <command>xmllint</command> to validate the + document:</para> <screen>&prompt.user; <userinput>xmllint --valid --noout example.xml</userinput></screen> - <para><command>xmllint</command> returns - without displaying any output, showing that the - document validated successfully.</para> + <para><command>xmllint</command> returns without displaying + any output, showing that the document validated + successfully.</para> </step> <step> <para>See what happens when required elements are omitted. - Delete the line with the <sgmltag class="starttag">title</sgmltag> and - <sgmltag class="endtag">/title</sgmltag> tags, and re-run the - validation.</para> + Delete the line with the + <sgmltag class="starttag">title</sgmltag> and + <sgmltag class="endtag">/title</sgmltag> tags, and re-run + the validation.</para> <screen>&prompt.user; <userinput>xmllint --valid --noout example.xml</userinput> example.xml:5: element head: validity error : Element head content does not follow the DTD, expecting ((script | style | meta | link | object | isindex)* , ((title , (script | style | meta | link | object | isindex)* , (base , (script | style | meta | link | object | isindex)*)?) | (base , (script | style | meta | link | object | isindex)* , title , (script | style | meta | link | object | isindex)*))), got ()</screen> - <para>This shows that the validation error comes from - the <replaceable>fifth</replaceable> line of the + <para>This shows that the validation error comes from the + <replaceable>fifth</replaceable> line of the <replaceable>example.xml</replaceable> file and that the - content of the <sgmltag class="starttag">head</sgmltag> is the part which - does not follow the rules of the <acronym>XHTML</acronym> grammar.</para> - - <para>Then <command>xmllint</command> shows - the line where the error was found and marks the - exact character position with a <literal>^</literal> sign.</para> + content of the <sgmltag class="starttag">head</sgmltag> is + the part which does not follow the rules of the + <acronym>XHTML</acronym> grammar.</para> + + <para>Then <command>xmllint</command> shows the line where + the error was found and marks the exact character position + with a <literal>^</literal> sign.</para> </step> <step> @@ -486,13 +495,15 @@ example.xml:5: element head: validity er <sect1 id="xml-primer-doctype-declaration"> <title>The DOCTYPE Declaration - The beginning of each document can specify - the name of the DTD to which the document conforms. - This DOCTYPE declaration is used by XML parsers to - identify the DTD and ensure that the document does conform to it. + The beginning of each document can specify the name of the + DTD to which the document conforms. This + DOCTYPE declaration is used by XML parsers to + identify the DTD and ensure that the document + does conform to it. A typical declaration for a document written to conform with - version 1.0 of the XHTML DTD looks like this: + version 1.0 of the XHTML + DTD looks like this: !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" @@ -512,8 +523,8 @@ example.xml:5: element head: validity er DOCTYPE - Shows that this is an XML declaration of the - document type. + Shows that this is an XML + declaration of the document type. @@ -528,21 +539,27 @@ example.xml:5: element head: validity er - PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" + PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" - Lists the Formal Public Identifier (FPI) + Lists the Formal Public Identifier + (FPI) Formal Public Identifier - for the DTD to which this document conforms. The XML - parser uses this to find the correct DTD when - processing this document. - - PUBLIC is not a part of the FPI, - but indicates to the XML processor how to find the DTD - referenced in the FPI. Other ways of telling the XML - parser how to find the DTD are shown DTD to which this document + conforms. The XML parser uses this to + find the correct DTD when processing + this document. + + PUBLIC is not a part of the + FPI, but indicates to the + XML processor how to find the + DTD referenced in the + FPI. Other ways of telling the + XML parser how to find the + DTD are shown later. @@ -551,7 +568,8 @@ example.xml:5: element head: validity er "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" - A local filename or a URL to find the DTD. + A local filename or a URL to find + the DTD. @@ -559,24 +577,29 @@ example.xml:5: element head: validity er > - Ends the declaration and returns to the document. + Ends the declaration and returns to the + document. - Formal Public Identifiers (<acronym>FPI</acronym>s) + Formal Public Identifiers + (<acronym>FPI</acronym>s) + Formal Public Identifier It is not necessary to know this, but it is useful - background, and might help debug problems when the XML - processor can not locate the DTD. + background, and might help debug problems when the + XML processor can not locate the + DTD. - FPIs must follow a specific syntax: + FPIs must follow a specific + syntax: "Owner//Keyword Description//Language" @@ -587,14 +610,18 @@ example.xml:5: element head: validity er The owner of the FPI. - The beginning of the string identifies the owner - of the FPI. For example, the FPI + The beginning of the string identifies the owner of + the FPI. For example, the + FPI "ISO 8879:1986//ENTITIES Greek Symbols//EN" lists ISO 8879:1986 as being the owner for - the set of entities for Greek symbols. ISO 8879:1986 is - the International Organization for Standardization (ISO) number for the SGML standard, the predecessor - (and a superset) of XML. + the set of entities for Greek symbols. + ISO 8879:1986 is the International + Organization for Standardization + (ISO) number for the + SGML standard, the predecessor (and a + superset) of XML. Otherwise, this string will either look like -//Owner @@ -608,19 +635,21 @@ example.xml:5: element head: validity er + identifying it as registered. - ISO 9070:1991 defines how registered names are - generated. It might be derived from the number of an ISO - publication, an ISBN code, or an organization code - assigned according to ISO 6523. Additionally, a + ISO 9070:1991 defines how + registered names are generated. It might be derived + from the number of an ISO + publication, an ISBN code, or an + organization code assigned according to + ISO 6523. Additionally, a registration authority could be created in order to - assign registered names. The ISO council delegated this - to the American National Standards Institute - (ANSI). + assign registered names. The ISO + council delegated this to the American National + Standards Institute (ANSI). Because the &os; Project has not been registered, - the owner string is -//&os;. As - seen in the example, the W3C are not a registered owner - either. + the owner string is -//&os;. As seen + in the example, the W3C are not a + registered owner either. @@ -632,11 +661,13 @@ example.xml:5: element head: validity er information in the file. Some of the most common keywords are DTD, ELEMENT, ENTITIES, - and TEXT. DTD is - used only for DTD files, ELEMENT is - usually used for DTD fragments that contain only entity - or element declarations. TEXT is - used for XML content (text and tags). + and TEXT. DTD is + used only for DTD files, + ELEMENT is usually used for + DTD fragments that contain only + entity or element declarations. TEXT + is used for XML content (text and + tags). @@ -655,9 +686,9 @@ example.xml:5: element head: validity er Language - An ISO two-character code that identifies - the native language for the file. EN - is used for English. + An ISO two-character code that + identifies the native language for the file. + EN is used for English. @@ -665,46 +696,46 @@ example.xml:5: element head: validity er <filename>catalog</filename> Files - With the syntax above, - an XML processor needs to have - some way of turning the FPI into the name of the file - containing the DTD. A - catalog file (typically called catalog) - contains lines that map FPIs to filenames. For example, if - the catalog file contained the line: + With the syntax above, an XML + processor needs to have some way of turning the + FPI into the name of the file containing + the DTD. A catalog file (typically + called catalog) contains lines that map + FPIs to filenames. For example, if the + catalog file contained the line: PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "1.0/transitional.dtd" - The XML processor knows that the DTD is - called transitional.dtd in the + The XML processor knows that the + DTD is called + transitional.dtd in the 1.0 subdirectory of the directory that held the catalog file. Examine the contents of /usr/local/share/xml/dtd/xhtml/catalog.xml. - This is the catalog file for the XHTML DTDs that was - installed as part of the XHTML + DTDs that was installed as part of the + textproc/docproj port. <envar>SGML_CATALOG_FILES</envar> - To locate a catalog file, - the XML processor must know where to look. Many - feature command line parameters for specifying the - path to one or more catalogs. - - In addition, - SGML_CATALOG_FILES can be set to point to the files. - This environment variable consists of a - colon-separated list of catalog files (including their full - path). + To locate a catalog file, the + XML processor must know where to look. + Many feature command line parameters for specifying the path + to one or more catalogs. + + In addition, SGML_CATALOG_FILES can be + set to point to the files. This environment variable + consists of a colon-separated list of catalog files + (including their full path). - Typically, the list includes these - files: + Typically, the list includes these files: @@ -724,30 +755,34 @@ example.xml:5: element head: validity er - This was done earlier. + This was done + earlier. Alternatives to <acronym>FPI</acronym>s - Instead of using an FPI to indicate the DTD to which - the document conforms (and therefore, which file on the system - contains the DTD), the filename can be explicitly specified. + Instead of using an FPI to indicate the + DTD to which the document conforms (and + therefore, which file on the system contains the + DTD), the filename can be explicitly + specified. The syntax is slightly different: !DOCTYPE html SYSTEM "/path/to/file.dtd" The SYSTEM keyword indicates that the - XML processor should locate the DTD in a system specific - fashion. This typically (but not always) means the DTD will - be provided as a filename. - - Using FPIs is preferred for reasons of portability. - If the SYSTEM - identifier is used, then the DTD must be provided and kept in the same location - for everyone. + XML processor should locate the + DTD in a system specific fashion. This + typically (but not always) means the DTD + will be provided as a filename. + + Using FPIs is preferred for reasons of + portability. If the SYSTEM identifier is + used, then the DTD must be provided and + kept in the same location for everyone. @@ -1031,9 +1066,11 @@ example.xml:5: element head: validity er the entity reference &version; replaced with the version number. Most web browsers have very simplistic parsers which do not handle XML DTD - constructs. Furthermore, the closing ]< - of the XML context are not recognized properly by browser and - will probably be rendered. + constructs. Furthermore, the closing + ]< of the XML context are not + recognized properly by browser and will probably be + rendered. + @@ -1349,20 +1386,19 @@ example.xml:5: element head: validity er The content model you will probably find most useful is CDATA. - CDATA is for Character - Data. If the parser is in this content model then - it is expecting to see characters, and characters only. In - this model the < and - & symbols lose their special status, - and will be treated as ordinary characters. + CDATA is for + Character Data. If the parser is in this + content model then it is expecting to see characters, and + characters only. In this model the < + and & symbols lose their special + status, and will be treated as ordinary characters. - When you use CDATA - in examples of text marked up in - XML, keep in mind that the content of + When you use CDATA in examples of + text marked up in XML, keep in mind that the content of CDATA is not validated. You have to - check the included XML text using other means. You - could, for example, write the example in another document, + check the included XML text using other means. You could, + for example, write the example in another document, validate the example code, and then paste it to your CDATA content. @@ -1482,8 +1518,8 @@ example.xml:5: element head: validity er - Modify the entities.ent file to contain - the following: + Modify the entities.ent file to + contain the following: <!ENTITY version "1.1"> <!ENTITY % conditional.text "IGNORE"> @@ -1499,13 +1535,15 @@ example.xml:5: element head: validity er - Normalize the example.xml file and notice - that the conditional text is not present on the output document. - Now if you set the parameter entity guard to INCLUDE - and regenerate the normalized document, it will appear there again. - Of course, this method makes more sense if you have more conditional - chunks that depend on the same condition, for example, whether you are - generating printed or online text. + Normalize the example.xml file + and notice that the conditional text is not present on the + output document. Now if you set the parameter entity + guard to INCLUDE and regenerate the + normalized document, it will appear there again. Of + course, this method makes more sense if you have more + conditional chunks that depend on the same condition, for + example, whether you are generating printed or online + text.