Introduction To Docbook 4 .5 Authoring

  • 6,093 views
Uploaded on

DocBook is a general purpose XML and SGML document type particularly well suited to books and papers about computer hardware and software (though it is by no means limited to these …

DocBook is a general purpose XML and SGML document type particularly well suited to books and papers about computer hardware and software (though it is by no means limited to these applications).

For sample code, Please see http://github.com/viswanath7/DocBook4.5/archives/master

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
6,093
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
0
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • DocBook XML is a structured future-proof content for publishers.
  • DocBook allows an author to concentrate on the organisation and meaning of the document, in order to ensure all documents have consistent appearance irrespective of the technical writer.
  • DocBook V5.0 is a test release at the time of writing this presentation.
  • XML catalog to locate the DTD With an XML catalog, you can have the best of both local and network access. The catalog lets you map the standard network URL to a local file. If the catalog processor finds the local file during processing, it will use it. Otherwise, it falls back to using the network URL. With this arrangement, you get the speed of local access with the reliability and portability of network access. An XML catalog entry looks like the following: <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"> <group id="DocbookDTD" prefer="public"> <system systemId="http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" uri="file:///usr/share/xml/docbook45/docbookx.dtd"/> </group> </catalog>
  • It doesn’t use an XML syntax and, as far as I know, it’s not an easy language.
  • Some authoring tools (like Adobe FrameMaker) provide ways to hide character entities form the author. Special characters are entered through its dedicated interface.
  • Remark RM : Why should I use a DocBook Package? Answer : You don’t have to but it is still good to know that such a thing exists.
  • Other root elements are also possible. The system identifier following the public identifier is just a backup in case the application can’t resolve the public identifier. In my opinion slide 32 to 39 should be recreated. Its better to first mention that you can have an external or an internal DOCTYPE declaration and explain the difference between them and tell that combinations are possible. After that you can say that you have PUBLIC and SYSTEM DOCTYPE declarations and explain when to use the public and system identifiers. I believe the information would be transferred to the audience in a more logical way.
  • The syntax: <!DOCTYPE root-element PUBLIC “ public identifier” “system identifier”> <!DOCTYPE root-element SYSTEM “system identifier”> Depending on the use of the public identifier the token ‘PUBLIC’ or ‘SYSTEM’ should be used.
  • The prefix is either a “+” or a “-” Registered public identifiers begin with “+”; unregistered identifiers begin with “-”. owner-identifier identifies the person or organization that owns the identifier. Registration guarantees a unique owner identifier The text class identifies the kind of document that is associated with this public identifier like DOCUMENT, DTD, ELEMENTS, ENTITIES, NONSGML text-description field provides a description of the document language indicates the language in which the document is written. ISO standard's two-letter language code is used if possible display-version distinguishes between public texts that are the same except for the display device or system to which they apply.
  • PUBLIC The PUBLIC keyword maps public identifiers to system identifiers: <public publicId="-//OASIS//DTD DocBook XML V4.5//EN" uri="docbookx.dtd"/> SYSTEM The SYSTEM keyword maps system identifiers to system identifiers: <system systemId="http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" uri="docbookx.dtd"/> <system systemId="http://docbook.org/xml/4.5/docbookx.dtd" uri="docbookx.dtd"/> OVERRIDE The OVERRIDE keyword indicates whether or not public identifiers override system identifiers. If a given declaration includes both a system identifer and a public identifier, most systems attempt to process the document referenced by the system identifier, and consequently ignore the public identifier. Specifying ‘OVERRIDE YES’ in the catalog informs the processing system that resolution should be attempted first with the public identifier. CATALOG The CATALOG keyword allows one catalog to include the content of another. DOCTYPE The DOCTYPE keyword allows you to specify a default system identifier
  • Entities help to reduce the entry of repetitive information and also allow for easier editing. There are two types of entity declarations: GENERAL entity declarations, and PARAMETER entity declarations. INTERNAL GENERAL ENTITY Declaration: Refer to data that an XML processor has to parse Syntax : <!ENTITY name "entity_value"> Example : <?xml version="1.0" standalone="yes" ?> <!DOCTYPE author [ <!ELEMENT author (#PCDATA)> <!ENTITY js "Jo Smith"> ]> <author>&js;</author> EXTERNAL (PARSED) GENERAL ENTITY Declaration: They are useful for creating a common reference that can be shared between multiple documents. There are two types of external entities: Private - Identified by the keyword SYSTEM and are intended for use by a single author or group of authors Syntax : <!ENTITY name SYSTEM "URI"> Example : <?xml version="1.0" standalone="no" ?> <!DOCTYPE copyright [ <!ELEMENT copyright (#PCDATA)> <!ENTITY c SYSTEM "http://www.xmlwriter.net/copyright.xml"> ]> <copyright>&c;</copyright> Public - Identified by the keyword PUBLIC and are intended for broad use. Syntax : <!ENTITY name PUBLIC "public_ID" "URI"> Example : <?xml version="1.0" standalone="no" ?> <!DOCTYPE copyright [ <!ELEMENT copyright (#PCDATA)> <!ENTITY c PUBLIC "-//W3C//TEXT copyright//EN" "http://www.w3.org/xmlspec/copyright.xml"> ]> <copyright>&c;</copyright> EXTERNAL (UNPARSED) GENERAL ENTITY Declaration: Refer to data that an XML processor does not have to parse. Syntax : <!ENTITY name SYSTEM "URI" NDATA name> <!ENTITY name PUBLIC "public_ID" "URI" NDATA name> Example : <?xml version="1.0" standalone="no" ?> <!DOCTYPE img [ <!ELEMENT img EMPTY> <!ATTLIST img src ENTITY #REQUIRED> <!ENTITY logo SYSTEM "http://www.xmlwriter.net/logo.gif" NDATA gif> <!NOTATION gif PUBLIC "gif viewer"> ]> <img src="logo"/> The PARAMETER ENTITY Declaration (not be used within mark-up in an internal DTD ) has following two types, INTERNAL - used to declare entities existing only in the DTD Syntax : <!ENTITY % name "entity_value"> Example : <!--external DTD example--> <!ELEMENT author (#PCDATA)> <!ENTITY % js "Jo Smith"> <!--note that the general entity statement below is used to reference a parameter entity--> <!ENTITY wb "written by %js;"> EXTERNAL - used to link external DTDs. Again, there are two types of external entities: private, and public. Syntax : <!ENTITY % name SYSTEM "URI"> %name; <!ENTITY % name PUBLIC "public_ID" "URI"> %name; Example : <?xml version="1.0" standalone="no"?> <!DOCTYPE student [ <!ENTITY % student SYSTEM "http://www.university.com/student.dtd"> %student; ]>
  • The DocBook definition of a book is very loose and general. Given the number of different conventions for book organisation used in various countries, attempting to impose a strict ordering of elements can make the content model extremely complex. Therefore, DocBook provides a free reign. It's common to use a local customisation layer to impose a more strict ordering for applications.
  • What is important is that you choose to mark up not every possible item, but only those for which distinctive tagging will be useful in the production of the finished document for the readers who will search through it.
  • If you try to use xref or link to cross reference to another file module, then your mini document is no longer valid. That is because those elements use an IDREF-type attribute to form the link, and the ID it points, must reside in the same document. They will be together when you assemble your modules into a larger document, but the individual mini documents will be incomplete. When you try to open such a module in a structured editor, it will complain that the document is not valid.
  • The value of href attribute in an XInclude can be an absolute path a relative path (taken as relative to the document that contains the XInclude element) an HTTP URL that accesses a web server or any other URI. Also, it can be mapped with XML catalog entries.
  • In theory you would be able to create a loop. Note : A document's root element can be an XInclude element. In that case, there should be only one such occurrence, since a well-formed document can only have a single root element. Likewise, the included content must resolve to a single element, with its children.
  • For selections based on id, the included document must have a DOCTYPE declaration that correctly points to the DocBook DTD. If the file does not have the DOCTYPE or if the DTD cannot be opened, then such references will not resolve. Note : When you omit the href attribute, and add an xpointer attribute, it is interpreted as selecting from the current document. One cannot select the entire document or that part of the document which has the XInclude element, because that would be a circular reference. Also, you don’t want to repeat content that has id attributes, as duplicate id values are invalid.
  • Note : The fallback content must be equally valid when inserted into the document for it to work.
  • Question RM : Do you also need Olink to make a link to a location in a file which is included in the file containing the Olink by XInclude? Remark RM : Perhaps you could make this process much clearer by illustrating it step by step.
  • Generally, the HTML files for multiple documents are output to different directories, particularly if chunks are used. Therefore one must decide the names and arrangement of the HTML output directories for all the documents in collection as a preliminary step. It is only the relative location that counts; the top level name is not used because the style-sheet computes the relative path for cross reference URLs using the relative locations. Chunking - It is the process of splitting the output for a large document into several HTML files. The individual output files are called chunks . The results are a coherent set of linked files, with a title page containing a table of contents as the starting point for browsing the set.
  • “ Only ” generates the target data file, but does not process the document for output. Use the option “ yes ” to also continue to process the document for output. When master target database document is processed, the content of the target.db file is assimilated into its proper location in the hierarchy using its system entity reference, thus forming the complete cross reference database. The use of system entities permits the individual target.db data files for each document to be updated as needed, and the database automatically gets the update the next time it is processed. If the DocBook chunking feature is used, then it would be the path to chunk.xsl instead.
  • target.database.document - provides the location of the master target database file. As the document is processed and when the style sheet encounters an olink that has targetdoc and targetptr attributes, it looks up the values in the target database and resolves the reference. If it cannot open the database or find a particular olink reference, then it reports an error. current.docid informs the processor of the current document's targetdoc identifier. Sometimes, current document's identifier is not recorded in the document itself, so the processor must be told of it by using this parameter. current.docid parameter can be automatically set if the id attribute of the document's root element is assigned the targetdoc value. This is accomplished by adding the following to customisation layer. <xsl:param name="current.docid" select="/*/@id"/>
  • Question RM : So this is a m * n relation?
  • Most are familiar with the term 'Web content management system'; which is a software used to manage and control a dynamic collection of web material. Primarily, maintenance tool designed to serve non-technical administrators; for a web-site that will constantly have new content (like products or company news) added /updated to it.
  • Compound document - A single document that contains a combination of data structures such as text, graphics, spreadsheets, sound and video clips. The document may embed the additional data types or reference external files by pointers of some kind. SGML and HTML are examples of compound document formats.
  • Most of us are familiar with the term 'Web content management system'; which is a software used to manage and control a dynamic collection of web material. Primarily, maintenance tool designed to serve non-technical administrators; for a web-site that will constantly have new content (like products or company news) added /updated to it.

Transcript

  • 1. DocBook - by Viswanath Jayachandran
  • 2. Quick introduction
    • DocBook is a very popular set of tags for describing books, articles, and other textual documents, particularly technical documentation.
    • DocBook is defined using the native DTD syntax of SGML and XML
  • 3. Quick introduction
    • DocBook is a XML vocabulary that enables us to author and store document content in a presentation-neutral form that captures the logical structure of the content.
    • DocBook XML can be used to transform in to numerous structured document and the content can be published in many formats.
  • 4. Quick introduction
    • DocBook XML is a structured future-proof content format for publishers.
    • It is easier to revise as it can be directly accessed by using popular desktop publishing softwares, such as, Adobe FrameMaker, InDesign, QuarkXpress, etc
  • 5. A more detailed look
  • 6. A detailed introduction to DocBook
    • DocBook is a strictly structured mark-up language very similar to HTML designed by OASIS consortium, specifically for technical documentation .
    • It provides a rich set of tags to describe the document’s content. The tags provide structure to the document and appear intermixed with informational text.
  • 7. A detailed introduction to DocBook
    • Technically, DocBook format is expressed in XML DTD and can thus profit from XML aware tools.
    • DocBook is not a presentation language. It specifies semantics rather than presentation. All the presentation issues are handled by style sheets.
  • 8. A detailed introduction to DocBook
    • Because of its modular organisation, DocBook is easily customisable to meet one’s requirements.
    • DocBook is extensive as it has a large number of tags that can accommodate a wide range of situations and processing expectations
  • 9. A detailed introduction to DocBook
    • DocBook uses long and self-explanatory tags that is a lot easier to read than an HTML source for example.
    • DocBook does not ensure upwards compatibility between major releases because it ensures a clean design even if wrong choices have been made previously by the DocBook Commitee at OASIS. Also, documents written with different DTDs can co-exist.
  • 10. Why DocBooks ? (Raison d'être)
    • Traditional approaches suffer from a few serious problems.
      • Longevity of the document was adversely affected – Information of significance is interspersed with information that will become obsolete ( like typesetting information)
      • Lack of structure - The traditional markup (like HTML) did not express content, but rather the page layout. Locating and indexing a semantic content of importance was a challenging task.
  • 11. Objective
    • Emphasise semantic content such that useful information can be extracted and indexed.
    • DocBook provides a very rich set of markup tags that relate to the structure and nature of the document’s content.
  • 12. Pro and con
    • Benefit
    • A search engine would provide the information actually sought without all the extra references that just happen to use those words casually.
    • Hurdle
    • DocBook has hundreds of tags (as opposed to just a few in HTML), hence the learning curve is steep.
  • 13. Getting started with DocBook
    • DocBook follows the syntax of XML, just like XHTML does. It can be converted to other formats through XSLT style sheets for instance, and a PDF layout can be accomplished through a XSL-FO engine.
  • 14. DocBook tools
    • DocBook-tools is a collection of free software tools necessary to work upon and format DocBook documents
    • The Docbook tools are categorised as
      • Authoring tools - Editing applications
      • Publishing tools - Transform DocBook to other formats
      • Convenience tools - Scripts, utilities, and web services that act as easier-to-use front ends to DocBook publishing tools.
  • 15. DocBook Authoring Tools
    • Validating editors are schema / DTD aware applications that interactively validate documents as user edits them.
    • Context-sensitive editors that provide off-the-shelf DocBook support.
    • Sometimes bundled with DocBook XSL stylesheets or other custom DocBook transformation support.
  • 16. DocBook Publishing Tools
    • Tools for transforming DocBook documents into other formats.
    • DocBook Publishing Tools are broadly classified as
      • DocBook specific publishing tools - Publishing tools designed specifically for use with DocBook include
      • XSL publishing tools - Tools in the DocBookXslStylesheets toolchain include general-purpose XSLT engines and FO engines.
      • DSSSL publishing tools
  • 17. DocBook toolchain
    • DocBook tools configured to work together are termed DocBook toolchain.
    • For instance, in <oXygen/> XML Editor, DocBookAuthoringTools contain publishing tool-chains built in.
    • It includes the Apache FOP Processor, for generating PDF and PostScript. Other FO processors can be configured as plug-in.
  • 18. Installation of DocBook DTD
    • Obtain DocBook from the website of Oasis that maintains it. The url is http://www.oasis-open.org/docbook/xml/4.5/docbook-xml-4.5.zip
    • At the time of writing this presentation, DocBook version 4.5 is the official latest version available. DTDs are available for both XML and SGML. The presentation confines its scope only to XML.
    • Other forms that are available like RELAX NG and W3C XML Schema are unofficial.
  • 19. Installation of DocBook DTD
  • 20. DocBook DTD
    • DocBook XML DTD consists of a main file docbookx.dtd that pulls several module files to form the complete DTD.
    • In XML documents, DTD(s) must be identified by means of a DOCTYPE declaration at the beginning of the XML file that provides the processor with clues for finding the DTD files.
    • The DOCTYPE declaration for network DTD access looks like the following
    • <!DOCTYPE book PUBLIC &quot;-//OASIS//DTD DocBook XML V4.5//EN&quot; &quot;http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd&quot;>
  • 21. DocBook stylesheets
    • DocBook stylesheets transform DocBook into some other format such as HTML, XSL-FO, nroff (man) pages, OASIS OpenDocument etc
    • DocBook stylesheets come in three flavours
      • DocBookDssslStylesheets – used with Jade/Openjade DSSSL engine
      • DocBookXslStylesheets – used with XSLT engines
      • DocBookCssStylesheets - used for controlling direct rendering of DocBook documents in Web browsers and in WYSIWYG XML editors.
    • DocBookXslStylesheets alone are in-scope of the presentation.
  • 22. DSSSL
    • DSSSL - Document Style Semantics and Specification Language.
    • A style sheet and transformation language for SGML documents. It allows an SGML document to be formatted for presentation or converted into another structure.
    • Jade is an example of a DSSSL processor written by James Clark.
  • 23. DocBookXslStylesheets
    • Designed and actively developed by NormanWalsh, stylesheets(docbook-xsl-doc-1.75.2.zip)are maintained by DocBookOpenRepository (http://sourceforge.net/projects/docbook/files).
    • DocBook XSL Configurator ( http://db-xsl-cfg.sourceforge.net ) contains swing applications used to create DocBook XSL customization layers (FO, HTML, and Manpages) and then execute external sub-processes to transform DocBook XML and view the output.
  • 24. Validation and Character entities
    • The DocBook DTD defines the character entities that make it easy to add special characters to your XML files.
      • For example - To enter a copyright symbol, for example, it is easier to remember a name like &copy; than the equivalent &#x00A9; Unicode entity.
    • Most XSL processors will not automatically validate your document while it is converting it.
  • 25. Validation and Character entities
    • The XSL processor will read a DOCTYPE declaration in the XML file and try to find the DTD, and will likely report an error if it cannot.
    • If it does find the DTD, it will read and use an entity declarations in it. Thus, If you use any DocBook character entities, the processor must be able to find the DTD to resolve those entity references.
    • DocBook stylesheets expect to be processing a valid document thus it is advised validate the documents prior to processing them.
  • 26. DocBook Packages
    • There are also package installation software available for various operating system platforms. For the Windows platform e-novative and CygwinPackages are good choices.
    • E-novative is DocBook environment for Windows released under GPL. It incorporates well-documented parametrisation and customisation of the original DocBook XSL stylesheets, enabling document type and document specific settings a breeze.
    • Cygwin is a Linux-like environment for Windows which enables us to use many standard UNIX utilities.
  • 27. e-novative DocBook Environment
    • eDE can be downloaded from http://www.e-novative.de/products/ede
    • eDE installs to c:docbook
    • The folders
      • dtd : Has the DocBook XML DTD.
      • fop : Has Apache Form Objects Processor to generate PDF documents
  • 28. e-novative DocBook Environment
    • include - Holds boilerplate texts that can be included into any eDE document
    • output - Has one subdirectoy for each eDE document. Each document subdirectory has a subdirectory for each output format.
    • repository - Each document directory consists of the DocBook XML source file, a subdirectory for all the figures to appear in the document and entities for document-specific boilerplate text.
  • 29. e-novative DocBook Environment
    • stylesheet – Holds XSL and CSS stylesheets.
    • template - eDE templates documents for articles, books and boilerplate text.
    • backup - Used by eDE to backup XML source files and settings on an update
    • xsl - Original DocBook XSL stylesheets that define the transformation from DocBook XML to the various output formats
    • deploy - one subdirectory for each document that holds a zip file for each output format.
  • 30. Creating DocBook Documents
    • Objective of this section is to provide basic skeletal information in order to write DocBook documents.
    • This section is designed to give an overview and certainly not an exhaustive list of every element’s detail in DocBook.
  • 31. Creating DocBook - XML basics
    • Identify the version of XML to ensure that future changes to the XML specification will not alter the semantics of the document.
    • The standalone declaration simply makes explicit the fact that this document cannot “stand alone,” and that it relies on an external DTD.
    • <?xml version=&quot;1.0&quot; standalone=&quot;no&quot;?>
  • 32. Creating DocBook - XML basics
    • Even though XML documents don't require a DTD, DocBook XML documents will mostly have one.
    • The DOCTYPE declaration below indicates that the root element will be <book> and that the DTD used will be the one identified by the public identifier --//OASIS//DTD DocBook XML V4.5//EN .
    • <!DOCTYPE book PUBLIC &quot;-//OASIS//DTD DocBook XML V4.5//EN&quot; “http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd”>
  • 33. Creating DocBook - XML basics
    • External declarations in XML must include a system identifier (the public identifier used here is optional).
    • <!DOCTYPE book PUBLIC &quot;-//OASIS//DTD DocBook XML V4.5//EN&quot; “http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd”>
    • System identifiers in XML must be URIs. Many systems may accept filenames and interpret them locally as file: URLs, but it's always correct to fully qualify them.
    • file:///usr/local/xml/docbook/4.5/docbook.dtd
  • 34. Creating DocBook - XML basics
    • When a DTD or other external file is referenced from a document, the reference can be specified in three ways: using
      • a public identifier ,
      • a system identifier , or
      • both.
    • In XML, the system identifier is generally required and the public identifier is optional.
  • 35. Creating DocBook - XML basics
    • A public identifier is a globally unique, abstract name.
    • The advantage of using the public identifier is that it makes documents more portable.
    • For any system on which DocBook is installed, the public identifier will resolve to the appropriate local version of the DTD (if public identifiers can be resolved at all).
  • 36. Creating DocBook - XML basics
    • A public identifier can be any string of upper- and lowercase letters, digits, any of the following symbols: “'”, “(“, “)”, “+”, “,”, “-”, “.”, “/”, “:”, “=”, “?”, and white space, including line breaks.
    • Most public identifiers conform to the ISO 8879 standard.
    • prefix//owner-identifier//text-class text-description//language//display-version
  • 37. Creating DocBook - XML basics
    • Catalog files are the standard mechanism for resolving public identifiers into system identifiers. See http://www.oasis-open.org/docbook/xml/4.5/catalog.xml
    • A catalog is a text file that contains a number of keyword/value pairs.
    • The most frequently used keywords are PUBLIC, SYSTEM, SGMLDECL, DTDDECL, CATALOG, OVERRIDE, DELEGATE, and DOCTYPE.
  • 38. Creating DocBook - XML basics
    • Internal Subset - It's also possible to provide additional declarations in a document by placing them in the document type declaration.
    • <?xml version=&quot;1.0&quot;?>
    • <!DOCTYPE author [ <!ELEMENT author (#PCDATA)> <!ENTITY email &quot;josmith@theworldaccordingtojosmith.com&quot;>
    • <!--the following use of a general entity is legal if it is used in the XML document-->
    • <!ENTITY js &quot;Jo Smith &email;&quot;> ]>
    • <author>&js;</author>
  • 39. Creating DocBook - XML basics
    • The declarations stored in the file referenced by the public or system identifier in the DOCTYPE declaration is called the external subset , which is technically optional. Note that these files do not and must not have document type declarations .
    • It is legal to put the DTD in the internal subset and to have no external subset, but for a DTD as large as DocBook, that would make very little sense.
    • <?xml version=&quot;1.0&quot; standalone=&quot;no&quot; ?>
    • <!DOCTYPE copyright [ <!ELEMENT copyright (#PCDATA)> <!ENTITY c SYSTEM &quot;http://www.xmlwriter.net/copyright.xml&quot;> ]>
    • <copyright>&c;</copyright>
  • 40. Categories of Elements in DocBook
    • DocBook elements can be broadly classified into the following :
    • Sets
    • Books
    • Divisions, - That divide books into parts
    • Components - That divide books or divisions into chapters
    • Sections - That subdivide components
    • Meta-information elements
    • Block elements
    • Inline elements
  • 41. Elements in DocBook - Sets
    • Sets – Hierarchical top of DocBook that contains more than one Books.
    • Set tag is typically used for a series of books on a particular subject that is accessed and maintained as a single unit.
    • Example : End user’s guide for a product.
  • 42. Elements in DocBook - Books
    • Most common top-level element in a document that consists of a mixture of the following elements
      • Dedication
      • Navigational Components
      • Divisions
      • Components
  • 43. Elements in DocBook - Books
    • Dedication frequently appears on a page by itself at the beginning of a book.
    • Navigational Components are component-level elements designed for navigation like
      • ToC, for Tables of Contents;
      • LoT, for Lists of Titles (for lists of figures, tables, examples, and so on); and
      • Index, for indexes.
  • 44. Elements in DocBook - Divisions and Components
    • Divisions are the first hierarchical level below Book. They contain
      • Parts – Contains components
      • References – Contains RefEntry
    • Components are chapter-like elements of a Book or Part. Books can contain components directly and are not required to contain divisions.
    • Components generally contain block elements and/or sections , but some can also contain navigational components and RefEntrys .
  • 45. Elements in DocBook - Sections
    • Sections sub-divide components and have several flavours. Namely,
      • Sect1…Sect5 elements
      • Section element
      • SimpleSect element
      • BridgeHead
      • RefSect1…RefSect3 elements
      • GlossDiv, BiblioDiv, and IndexDiv
  • 46. Elements in DocBook - Meta-Information
    • Wrapper designed to contain
      • Bibliographic information about the content (Author, Title, Publisher etc) and
      • Other meta-information (such as revision histories, keyword sets, and index terms.
    • Applies to all the elements at the section level and above
  • 47. Elements in DocBook – Paragraph level elements
    • At the paragraph-level, elements are divided into
        • Block and
        • Inline
      • elements from a structural point of view based on their relative size.
    • Block elements are presented with a paragraph break before and after them. Usually, they contain other block elements, character data and inline elements.
  • 48. Elements in DocBook – Block Elements
    • Block elements occur immediately below the component and sectioning elements.
    • They can be divided into a number of categories:
      • Lists
      • Admonitions
      • Line-specific environments
      • Synopses of several sorts
      • Tables
      • Figures
      • Examples and
      • A dozen or more miscellaneous elements.
  • 49. Elements in DocBook – Inline Elements
    • Inline elements are generally represented without any obvious breaks. They may be distinguished through a change in font or may also have absence of visual distinction.
    • Inline elements are used to mark up data such as cross references, filenames, commands, options, subscripts and superscripts, and glossary terms.
    • Inline elements contain character data and possibly other inline elements, but they never contain block elements.
  • 50. Elements in DocBook – Inline Elements
    • Sub categories of inline elements are as follows.
      • Traditional publishing inlines – Identify items that occur in general writing. Like Acronym, Footnote, Trademark, Footnote, Quote etc.
      • Cross references – Identify both explicit cross references such as Link and implicit cross references like GlossTerm.
      • Markup - used to mark up text for special presentation
      • Mathematics – elements representing equations
      • User interfaces – elements that describe the aspect of a UI
      • Programming languages and constructs
      • Operating System
      • General purpose
  • 51. Creating a DocBook - Book
    • A typical Book, in English at least, consists of
      • Some meta-information in a BookInfo (Title, Author, Copyright, and so on)
      • One or more Prefaces
      • Several Chapters and
      • Perhaps a few Appendixes.
    • A Book may also contain
      • Bibliographies
      • Glossaries
      • Indexes and
      • A Colophon.
    • See the example for a typical book in english
  • 52. Creating a DocBook - Chapter
    • Chapter(s), Preface(s), and Appendix(es) have a similar structure. They consist of a
      • Title
      • Meta-information (optional)
      • Block-level element(s) followed by top level section(s)
        • Each section may in turn contain any number of block-level elements followed by next section level
    • See the example for better understanding.
  • 53. Creating a DocBook - Article
    • Article is the most logical starting point for documents smaller than books like journal, white-paper, technical notes etc.It has same body as any component-level element like chapter.
    • An Article is composed of a header and a body.
    • Please take a moment to look at the sample article.
  • 54. Creating a DocBook – Para
    • A Para is a paragraph in DocBook that may contain almost all inline and most block elements.
    • DocBook offers two variants of paragraph apart from the general Para element
      • SimPara - cannot contain block elements
      • FormalPara - has a title
    • Look at the example for better understanding.
  • 55. Creating a DocBook - Literal
    • Other frequently used elements of DocBook DTD include literal.
    • A literal is some specific piece of data, taken literally, from a computer system.
    • A literal is frequently distinguished typographically and its ‘moreinfo’ attribute can help generate a link or query to retrieve additional information.
    • Again, please take a look at the example
  • 56. Creating a DocBook - Others
    • The XRef element forms a cross-reference from its location to another part of document it points.
    • <xref linkend=&quot;text-of-the-link“ endterm=&quot; cross-reference-target &quot;/>
    • Also see mediaobject and table
  • 57. Modular DocBook files
    • Modular DocBook means your content collection is broken up into smaller file modules that are recombined for publication.
    • The advantages of modular documentation include:
      • Reusable content units.
      • Smaller file units to load into an editing program.
      • Distributed authoring.
      • Finer grain version control.
    • The best tools for modular documentation are XIncludes and olinks.
  • 58. Modular DocBook files - XInclude
    • XInclude replaces the old way of using system entities that were always a problem as system entities cannot have a DOCTYPE declaration, and therefore cannot be valid documents on their own.
    • However with XInclude, the modular files can be valid mini documents, complete with DOCTYPE declaration.
    • Conveniently, the module's DOCTYPE does not generate an error when its content is injected using the XInclude mechanism.
  • 59. Modular DocBook files - Olink
    • Olinks enable us to form cross references among modular files.
    • Olinks do not use IDREF attributes to form the cross reference; instead they are resolved by the style sheet at run-time, whether you are processing a single module or the assembled document.
  • 60. Modular DocBook files - using XInclude
    • Synopsis : One can divide the content into several valid file modules, and use XInclude to assemble them into larger valid documents.
    • For example, each chapter of a book can be separated into its own document file for writing and editing; that can later be assembled into a book for processing and publication.
    • Please see the example.
  • 61. Modular DocBook files - using XInclude
    • Constituting or Embodying file modules of a Docbook must have a complete DOCTYPE declaration to identify it as a mini-document. Unless otherwise specified, an XInclude fetches the root element and all its children.
    • The syntax for the inclusion is an empty element whose name is include, that is defined in the namespace for XInclude. It is customary to use the prefix xi:. The href attribute contains a URI that points to the file to include.
  • 62. Modular DocBook files - using XInclude
    • When the XInclude is resolved during the processing, the <xi:include> element will be replaced by the included chapter element and all of its children.
    • It is the author's responsibility to ensure that the included content is valid in the location where it is injected.
    • One can also nest Xincludes.
  • 63. Modular DocBook files - using XInclude
    • XInclude standard permits us to select a part of a file for inclusion instead of the entire file.
    • In a modular source setup, that means we can organise our modules into logical units for authoring, and perform selections from the content of a file module when required.
    • The simplest syntax just has an id value in an xpointer attribute.
    • <xi:include href=&quot;intro.xml&quot; xpointer=&quot;Installing&quot; xmlns:xi=&quot;http://www.w3.org/2001/XInclude&quot;/>
    • More complex selections can be made using the full XPointer syntax.
  • 64. Modular DocBook files - using XInclude (Including plain text)
    • The attribute parse=&quot;text&quot; attribute of XInclude facilitates us by indicating the processor to treat the incoming content as plain text instead of the default XML.
    • XInclude can thus be used to include plain text files by pointing the href attribute to the file-name. The encoding of the incoming text is specified by adding an encoding attribute.
    • Since the included text is not XML, one cannot use an xpointer attribute with XPointer syntax to select part of it.
  • 65. Modular DocBook files - using XInclude (fallback mechanism)
    • XInclude contains some fallback content that permits processing to continue if an include cannot be resolved at runtime.
    • Usage : Insert a single xi:fallback child element to indicate that the content of the child should be used if XInclude resolution fails.
    • <xi:include href=&quot;intro.xml&quot; xmlns:xi=&quot;http://www.w3.org/2001/XInclude&quot;>
    • <xi:fallback>
    • <para>FIXME: MISSING XINCLUDE CONTENT</para>
    • </xi:fallback>
    • </xi:include>
  • 66. Modular DocBook files - using XInclude (fallback mechanism)
    • xi:fallback element can contain another xi:include , which the processor will try to resolve as a secondary resource. The secondary include can also contain a secondary fallback, and so on.
    • Processing of a document does not stop when an XInclude cannot be resolved and it has a fallback child, even if that child is empty.
    • Usage guideline - If you want your processing to always continue regardless of how the includes resolve, then add a fallback element to all of your XInclude elements. Otherwise, do not use fallback elements on the innermost includes and let the processing fail.
  • 67. Modular DocBook files - using XInclude (entities for filenames)
    • XIncludes are intended to replace SYSTEM entities but it’s still possible to use regular entities with XInclude.
    • Typical usage : One can declare regular entities for filenames in a file's DOCTYPE declaration, and subsequently use an entity reference in the href attribute of an XInclude element. That allows us to more easily manage various file includes instead of scattering them throughout.
    • See the example.
  • 68. Modular DocBook files - using Olink
    • Steps to form cross linking between documents using ‘olinks’
    • Identify the documents that have to be included in the domain for cross referencing and assign each of them a document id.
    • Insert an olink element in your document where a cross reference has to be formed to another document.
      • An olink contains two attributes namely; ' targetptr ' and ' targetdoc '. ' targetdoc ' is the document id of the destination end of the link and ' targetptr ' is the xml:id value of the element in that target document.
  • 69. Modular DocBook files - using Olink
    • In order to form cross references between documents in HTML, one must be aware of their relative locations .
    • Create a master target database document for the collection that resolves all olinks for every document in the collection.
    • Since all the document data is gathered dynamically, the target database document is authored manually and is static, except for changes to the collection.
  • 70. Modular DocBook files - using Olink
    • For each document in the collection, generate a data file that contains all the potential cross reference targets. It is accomplished by processing the document using regular DocBook XSL stylesheet but with an additional collect.xref.targets parameter. See an example below that should generate in the current directory a target data file, named target.db by default
      • xsltproc
      • --stringparam collect.xref.targets &quot;only&quot;
      • docbook.xsl
      • userguide.xml
  • 71. Modular DocBook files - using Olink
    • Process each document to generate its output using the normal XSL DocBook stylesheet with an additional parameter which is the database filename.
    • xsltproc --output /http/guides/mailuser/userguide.html
    • --stringparam target.database.document &quot;olinkdb.xml&quot;
    • --stringparam current.docid &quot;MailUserGuide&quot;
    • docbook.xsl userguide.xml
  • 72. DocBook 5
    • DocBook 5 is the next generation of DocBook that significantly changes the foundation on which DocBook is based.
    • The version 5.0 (under active development) is a complete rewrite of DocBook in RELAX NG.
    • The Technical Committee has simplified a number of content models and tightened constraints where RELAX NG makes them possible.
    • The Technical Committee provides the DocBook 5.0 schema in other schema languages, including W3C XML Schema and an XML DTD, but the RELAX NG Schema is the normative schema.
  • 73. DocBook 5
    • All element in DocBook 5 are defined in the namespace http://docbook.org/ns/docbook
    • In DocBook 4.x, only a few elements like link and xref were used to form links. In DocBook 5, most elements that generate some output can be made into a link with a set of attributes that are defined in the XLink namespace. The link can go to an internal or external destination. Also, the id attribute is replaced with the xml:id attribute.
  • 74. DocBook 5
    • In DocBook 5, elements from DocBook 4 such as bookinfo, chapterinfo, sectioninfo , etc. are all replaced by a single info element.
    • RelaxNG permits an element to have a different content model when the element appears in a different context.
    • For example, the DocBook 5 info element in book can contain a title , but the info element in para cannot.
  • 75. DocBook 5
    • DocBook 5 has a new system for associating annotations with elements. It defines two new elements namely;
      • alt for short description
      • annotation for an arbitrarily complex description.
    • Example of alt
    • <mediaobject>
    • <alt>mouse buttons</alt>
    • <imageobject>
    • <imagedata fileref=&quot;mouse.png&quot;/>
    • </imageobject>
    • </mediaobject>
  • 76. DocBook 5
    • Annotation meets the needs when alt is limited. An annotation element's content can be any mix of DocBook block elements.
    • An annotation is associated with an element using attributes, not by placement. Specifically :
      • An annotates attribute on an annotation element matches the value of the xml:id of the element it is annotating.
      • An annotations attribute on any element matches the value of the xml:id of an annotation element associated with it.
    • Both attributes accept multiple space-separated values. One can assign a role attribute to an annotation to identify it as a certain kind of annotation. There are no predefined role values.
  • 77. Industry's trend : WYSIWYG XML Editing
  • 78. Introduction to WYSIWYG
    • WYSIWYG - What You See Is What You Get
  • 79. Introduction to WYSIWYG
    • Problem – Often, ones who maintain the content of a web-site (typically through a WCM in a large corporation) have beginners knowledge of a web-developer.
    • One of the elegant solutions – To provide the company with a browser based WYSIWYG editor similar to Microsoft's FrontPage or Adobe's Dreamweaver.
  • 80. What is a WYSIWYG ?
    • WYSIWYG implies a user interface that allows the user to view something very similar to the end result while the document is under creation.
    • WYSIWYG encompasses the user interfaces in
      • Presentation programs, Word Processing applications and Desktop Publishing applications for Compound documents (including web pages)
      • 3D computer graphics or 3D models in computer-aided design.
  • 81. Support for WYSIWYG in web browsers
    • Internet Explorer 5 and later supports a set of commands to facilitate complete browser based content creation.
    • Firefox also provides WYSIWYG widgets within Web CMS systems using Mozilla's &quot;extensions&quot; paradigm as well as its API facilities. Please follow this link for more information .
  • 82. Support for WYSIWYG in operating systems
    • Mac OS X and all higher versions support unconstrained glyph placement.
    • Applications for Microsoft windows that use the windows presentation foundation (included with the OS since windows vista), may also freely place glyphs.
    • By default, the positioning and spacing of glyphs on-screen will exactly match the printed documents.
  • 83. WYSIWYG XML editors
    • Author mode of the < oXygen /> XML Editor
    • Adobe FrameMaker
    • Syntext Serna Enterprise WYSIWYG XML editor
    • Web based editors
    • BXE (open source)
    • Xopus (proprietary)
  • 84.
    • Xopus is a WYSIWYG XML Editor that runs in web-browsers (Firefox and Internet explorer). It presents the author with a friendly interface to structured and complex XML content where the author cannot break the XML structure or write content that does not conform to the XML Schema.
    • Quality and consistency of xml documents can be controlled as they could be necessitated to conform to enterprise standards such as DITA and DocBook.
    Xopus – An WYSIWYG XML editor
  • 85. Xopus – An WYSIWYG XML editor
    • As it's based on popular open standards such as XML, XML Schema, XSLT, Javascript and CSS stylesheets, it is easy to integrate Xopus into web server environments and content management systems.
    • It supports rich copy-paste from applications, such as Microsoft Word and Open Office, change tracking, spell checking and multi-lingual support in the user interface.
  • 86. Demo
  • 87. The road ahead
    • Parsing and publishing DocBook documents
    • Customising DocBook documents
  • 88. Time to answer your questions