Chapter 45. How to write ProActive documentation

45.1. Aim of this chapter

This chapter is meant to help you as a reference for writing ProActive-directed documentation. If you have added a new feature and want to help its uptake by documenting it, you should be reading this chapter.

The examples sections (Section 45.3, “Example use of tags”) describes the use of the main tags you will use (eventually, all the ProActive-allowed docbook tags should be described). The limitations (Section 45.4, “DocBok limitations imposed”) section describes what is allowed in our docbook style, and why we restrict ourselves to a subset of docbook.

45.2. Getting a quick start into writing ProActive doc

First off, all the documentation is written in docbook. You can find all the documentation source files in the ProActive/doc-src/ directory.

Here are the instrtuctions to follow to start well & fast writing documentation for the ProActive middleware:

  1. Get a working copy of the XMLMind XML Editor (XXE)

  2. If you want a new chapter of your own, copy one of the existing files. (ProActive/doc-src/WSDoc.xml for example)

  3. Reference your file in the root element of the doc (it is currently called PA_index.xml)

  4. Open your file with XXE (it should not complain)

    • REMEMBER: YOU ARE EDITING AN XML FILE - you can always edit it with vi if you dare

    • Use generously the icons at the top, they have the essential tags you will use

    • Use the list of tags, just under the icons, to select the item you want to edit

    • Use the column on the right to add tags, when you know their names

    • When you're done, there is a spellchecker intergated, as well as a DocBook validator. Please use these tools!

  5. Make sure your new additions make a nice new document. Run the ant target build manualHtml, and you should have an html copy of the doc. If you want to generate all the possible output formats, call build manual. You can also see what the results seem to be without compiling! Try to open one of the docbook xml files in a browser (mozilla/firefox do it) and you have a preview of what it might look like. Those who dislike XXE should be more than happy of it...

  6. Commit your changes to the svn repository

45.3. Example use of tags

These are the basic rules to follow to use docbook tags. This document is made up of the files in the docBookTutorial directory, and you may find it with the other manual files in the 'doc-src' directory.

45.3.1. Summary of the useful tags

The main tags/structures you should be using are:

  • <figure> When you want an image

  • <example> when you want an example with a title (should contain a <screen> or <programlisting>). You can also use <literal> inside paragraphs.

  • <screen> or <programlisting> for the code/text/descriptor examples

  • <para> to start a paragraph, <sectX>, with X=1..4 to have headings, and <emphasis> when you want some particular bit to stick out.

  • <itemizedlist> followed by several <listitem> when you want bullets

  • <xref> when you want to reference another section/chapter/part

  • <ulink> when you want to reference a web url

  • <table> when you want a table

[Note]Note

BUT, you should always be using the XXE icons. They have all you need (except for EXAMPLE/SCREEN)! You can also cut n paste!

45.3.2. Figures

This is the figure example. Please use the TITLE tag

A Drawing using the FIGURE tag

Figure 45.1. A Drawing using the FIGURE tag

45.3.3. Bullets

Use ITEMIZEDLIST followed by as many 'LISTITEM's as you want!

  • Provide an implementation for the required server-side functionalities

  • Provide an empty, no-arg constructor

  • Write a method in order to instantiate one server object.

45.3.4. Code

Code sources should be written between PROGRAMLISTING tags (possiblibly lang="java" or "xml" ). You don't have to write valid code, as the highlighting (done by LanguageToDocBook classes) is based on regular expression replacement, and not on language grammars. If you want to show some program output, you can use SCREEN instead of PROGRAMLISTING. In any case, watch out, because spaces count (and produce your own indentation)! You can also use the EXAMPLE TAG around your PROGRAMLISTING or SCREEN tags, to give a title, and be referenced in the table of examples.

You can also insert directly sources from their original files, or type the code in the docbook. When you are typing the code inside the docbook file, you can even highlight yourself some bits of the code you want to emphasis. This is shown in the last example. But beware, as you are inside docbook you have to escape the "&" and the "<" signs. If you don't want to, hide everything in a CDATA block.

Within normal text, for instance in a paragraph, you can also just use the LITERAL tag to highlight the main methods.

     public class TinyHello implements java.io.Serializable {
    static Logger logger = ProActiveLogger.getLogger(Loggers.EXAMPLES);
    private final String message = "Hello World!";

    /** ProActive compulsory no-args constructor */
    public TinyHello() {
    }

    /** The Active Object creates and returns information on its location
     * @return a StringWrapper which is a Serialized version, for asynchrony */
    public StringMutableWrapper sayHello() {
        return new StringMutableWrapper(
            this.message + "\n from " + getHostName() + "\n at " +
            new java.text.SimpleDateFormat("dd/MM/yyyy HH:mm:ss").format(new java.util.Date()));
    }

    /** finds the name of the local machine */
    static String getHostName() {
        try {
            return java.net.InetAddress.getLocalHost().toString();
        } catch (UnknownHostException e) {
            return "unknown";
        }
    }

    /** The call that starts the Acive Objects, and displays results.
     * @param args must contain the name of an xml descriptor */
    public static void main(String[] args)
        throws Exception {
        // Creates an active instance of class Tiny on the local node
        TinyHello tiny = (TinyHello) ProActive.newActive(
                TinyHello.class.getName(), // the class to deploy
                null // the arguments to pass to the constructor, here none
            ); // which jvm should be used to hold the Active Object

        // get and display a value 
        StringMutableWrapper received = tiny.sayHello(); // possibly remote call
        logger.info("On " + getHostName() + ", a message was received: " + received); // potential
 wait-by-necessity
        // quitting
        
        ProActive.exitSuccess();
    }
}

    

Example 45.1. JAVA program listing with file inclusion

     <?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE definition PUBLIC "-//objectweb.org//DTD Fractal ADL 2.0//EN"
 "classpath://org/objectweb/proactive/core/component/adl/xml/proactive.dtd">

<!-- A user component. It has an interface to the dispatcher. -->

<definition name="org.objectweb.proactive.examples.components.c3d.adl.UserImpl">

<!-- The interfaces the component defines -->
  <interface signature="org.objectweb.proactive.examples.c3d.Dispatcher" role="client" name=
"user2dispatcher"/>

<!-- The implementation of the component -->
  <content class="org.objectweb.proactive.examples.components.c3d.UserImpl"/>
  <controller desc="primitive"/>

<!-- deploy this component only on 'User' VirtualNodes (which must be found in the deploy.
 descr.) -->
  <virtual-node name="User" cardinality="single"/>

</definition>

    

Example 45.2. XML program listing with file inclusion

A screen example, for instance some code inside a unix shell:

linux > start.sh & 

Here is some java code directly included in the docbook (you can use CDATA to escape & and <):

package util;
                                                   
import java.io.IOException;
                                                   
/** Just a dummy class. */

public class Dummy {
                                                   
  /** Just the method description 
   * @param fileToConvert the name of the file to convert 
   * @return a String created  */   
  String convert(String fileToConvert) throws IOException {
    if (a > b && c < d ) {
      // can use "this" for 'NodeCreationEvent'
      VirtualNode vn = pad.getVirtualNode("p2pvn");
      vn.start();
      }
    return "Hello World";      
  }
                                                                    
}

Here is an example of deployment descriptor that deploys 3 virtual nodes .

 <!-- Deploying 3 virtual Nodes  -->
 <ProActiveDescriptor>                        
  <componentDefinition>
   <virtualNodesDefinition>
    <virtualNode name="NonFT-Workers" property="multiple"/>
    <virtualNode name="FT-Workers" property="multiple" ftServiceId="appli"/>
    <virtualNode name="Failed" property="multiple" ftServiceId="resource"/>
   </virtualNodesDefinition>
  </componentDefinition>
  
  <deployment>
     <mapping>
      <map virtualNode="NonFT-Workers">
       <jvmSet>
        <vmName value="Jvm1"/>
       </jvmSet>
      </map>
      <map virtualNode="FT-Workers">
       <jvmSet>
        <vmName value="Jvm2"/>
       </jvmSet>
      </map>
    ....

45.3.5. Links

Use XREF tags to point to the Figures id (Section 45.3.2, “Figures”) which is in the doc above. The LINKEND attribute points to the id which is referenced, for example, in a SECT1 tag. The ENDTERM tag (example with the biblio) is used to customize the string which will be used to point to the reference.

You can also use XREF to include files which are in the html hierararchy already. This goes for java files, and deployment descriptors. You have a few examples in Descriptor.xml. (technical note: including files is done through the java files in util. This may be done in pure xsl, but I gave up! The pdf and html look different thanks to profiling)

Use ULINK tags to point to web references (ProActive for instance). Use freely, it sticks out nicely in pdf too!

Use CITATION followed by an XREF for citations. For example, see [BBC02] to learn on groups. All the biblio entries should be put in biblio.xml. You should consider using the bibdb tool to convert from bibtex (http://charybde.homeunix.org/~schmitz/code/bibdb/).

45.3.6. Tables

The tag to use is TABLE.

Name

Hits

Bob

5

Mike

8

Jude

3

Table 45.1. This is an example table

45.4. DocBok limitations imposed

Here is described what is allowed in our docbook style. We restrict ourselves to a subset of docbook, because we want a uniform doc style, and want maintainable doc. To achieve this goal, we require minimum learning investment from our PA developers, who are meant to be coding, not spend their time writing doc. So you still want to add a fancy feature? Well, you can, as long as you describe how to use this new tag in this howto, and be extra careful with the pdf output.

There is a schema specifying which are the allowed tags. You can only use the tags which this dtd allows. If you want more freedom, refer to Section 45.5.6, “DocBook subset: the dtd”. For now, you can use the following tags:

  • part, appendix, chapter, sect[1-5], title, para, emphasis, xref, ulink

  • table, figure, caption, informalfigure, informaltable

  • itemizedlist and orderedlist, listitem

  • example, programlisting, screen, and literal

  • The others that you might come along, albeit less frequently, are citation, email, indexterm, inlinemediaobject, note, answer, question, subscript, superscript

45.5. Stylesheet Customization

Ok, now you're nearly a docbook guru? You want to get right down to the entrails of the machinery? OK, hop on and enjoy the ride! Here are a few notes on how you should go about customizing the output. That means, changing how the pdf and html are written.

45.5.1. File hierarchy

The files for configuration are the following:

  • common.xsl This is where all the common specifications are made, ie those that go and in pdf and in html.

  • pdf.xsl This is where all the pdf specific customizations are made

  • html.xsl This is where most html specific customizations are made.

  • onehtml.xsl and chunkedhtml.xsl, specifics for html, the former on one page, "chunked", one file per chapter, for the latter.

  • ProActive.css Which is yet another extra layer on top of the html output.

45.5.2. What you can change

Basically, in the customization layers, you have full control (just do what you want). The only thing is that each block (template, variable...) should be described by a comment. That will help later users. As customization can get cryptic, make a special effort!

45.5.3. The Bible

The book you want to have with you is the following: "DocBook XSL: The Complete Guide", Third Edition, by Bob Stayton, online version at http://www.sagehill.net.

Have a look at the index if you just want to change a little something in the customization. Parse through it at least once if you intend to do some heavy editing. I have found everything I needed in this book, but sometimes in unexpected sections.

45.5.4. Profiling

If you want to write some stuff that should go in pdf but not html, or vice-versa, you want to do some "profiling". This is very easy to do, as it was needed and tuned for the processing stages. Add an "os" attribute to the sections you want to exclude, specifying the wanted output format in which it should only appear.

 <para os="pdf"> This paragraph only appears in pdf output! </para>

(Comment) Using the "os" attribute to specify the output is not elegant. Agreed. But in docbook there is no default attribute intended to express the expected output file format, and using the "role" attribute is discouraged.

45.5.5. The XSL debugging nightmare

If you are editing the xsl stylesheets, and are having a hard time figuring out what's happening, don't panic! Use many messages to find out what the values of the variables are at a given time:

<xsl:message>
     <xsl:text> OK, in question.toc, id is </xsl:text> <xsl:copy-of select="$id" /> 
    </xsl:message>
    
    <xsl:for-each select="./@*">
     <xsl:message>
      <xsl:text> Attribute  <xsl:value-of select="name(.)"/> = <xsl:value-of select="."/>  </xsl:text> 
     </xsl:message>
    </xsl:for-each >  

You will very soon find that you still have to dig deeper into the templates, and they certainly are not easy to follow. Here's a little helper:

java -cp $CLASSPATH org.apache.xalan.xslt.Process -TT -xsl ...  -in ... -out ...
This uses the specified templates with the xsl file specified, but tracing every template called. Useful when you're wondering what's being called. I'm sorry but I have not found a way to trace the call tree of a method, ie knowing exactly where it comes from. Have to do without!

45.5.6. DocBook subset: the dtd

The dtd is the file detailling which are the allowed tags in our DocBook subset. Some tags have been removed, to make it easier to manage. Please refer to the file called ProActive/doc-src/ProActiveManual.dtd to know how much freedom you have been granted.

When you run the manual generation through the ant tasks, the xml is checked for validity. The message you should see is

XML is VALID and complies to dtd in ../docs/tmp/PA_index.xml

If you happen to modify the dtd, you should put also copy it on the web, on /proj/oasis/www/proactive/doc/dtd/$version/ or else the previous version one will always be used.

45.5.7. Todo list, provided by Denis

  1. Ensure no dead links exist (easy with wget --spider OR http://www.dead-links.com/ for html, harder for the pdf).

  2. Create an index, and put the main words in it

  3. All important code examples should be wrapped in EXAMPLE tags