The Documentation Project is trying to use SGML as the standard method of representing the documentation.
SGML is the Standard Generalised Markup Language.
In a nutshell (and apologies to any SGML purists in the audience that are offended) SGML is a language for writing other languages.
You have probably already used SGML, but you did not know it. HTML, the language that web pages are written in, has a formal description. That description is written in SGML. When you are writing HTML you are not writing SGML (per se), but you are using a language that is defined using SGML.
There are many, many markup languages that are defined using SGML. HTML is one of them. Another is called "LinuxDoc". As you can probably guess, it was originally created by the Linux documentation group to write their documentation, and the FreeBSD Documentation Project adopted it as well.
Another markup language defined using SGML is called "DocBook". This is a language designed specifically for writing technical documentation, and as such it has many tags (the things inside the <...>) to describe technical documentation related things.
For example, this is how you might write a brief paragraph in HTML (do not worry about the content, just look at the tags):
The system's passwords are stored in /etc/passwd. To edit
this file you should use vipw. However, if you just
want to add a new user you can use adduser.
]]>
The same paragraph, marked up using DocBook, looks like
The system's passwords are stored in
/etc/passwd . To edit this file you should use
vipw . However, if you just want to add a new user
you can use adduser .
]]>
As you can see, DocBook is much more 'expressive' than HTML. In the HTML example the filename is marked up as being displayed in a 'typewriter' font. In the DocBook example the filename is marked up as being a 'filename', the presentation of the filename is not described.
There are a number of advantages to this more expressive form of markup:
It is not ambiguous or inconsistent.
You do not spend time thinking "Hmm, I need to show a filename, should I use 'tt', or 'b', or 'em'?"
Instead, you just use the right tag for the right job.
The conversion process from DocBook to other formats (HTML, Postscript, and so on) makes sure that all <filename>'s are shown the same way.
You stop thinking about the presentation of your document, and instead concentrate on the content.
Because the documentation is not tied to any particular output format, the same documentation can be produced in many different formats - plain text, HTML, Postscript, RTF, PDF and so on.
The documentation is more 'intelligent', so more intelligent things can be done with it. For example, it becomes possible to automatically produce an index of the documentation that lists every command shown in the documentation.
If you are familiar with them, this is a bit like Microsoft Word stylesheets, only vastly more powerful.
Of course, with this power comes a price;
Because the number of tags you can use is much larger, it takes longer to learn all of them, and how to use them effectively.
I found the best way to learn was to read the source to lots of example documents, seeing how other authors had written similar information.
The conversion process is not that simple.
Right now, the Project is still using LinuxDoc for the Handbook and the FAQ. That's changing, and in particular there's a project underway to convert the documentation to DocBook.
Yes you can. Quite definitely. Any documentation is better than no documentation. If you've got some documentation to contribute and it's not marked up in LinuxDoc or DocBook, don't worry.
Submit the documentation as normal. Someone else on the Project will grab your committed documentation, mark it up for you, and commit it. With a bit of luck they'll then send you the marked up text back. This is handy because you can do a "before and after" shot of the plain documentation and the marked up stuff, and hopefully learn a bit more about the markup in the process.
Obviously, this slows down the committing process, since your submitted documentation needs to be marked up, which may take an evening or too. But it will get committed.
You should first read the Documentation Project Primer. This aims to be a comprehensive explanation of everything you need to know in order to work with the FreeBSD documentation.
This is a long document, split in to many smaller files. You can also view it as one large file.
The SGML/XML web page. Includes countless pointers to more information about SGML.
The "Gentle Introduction to SGML". Recommended reading for anyone who wants to learn more about SGML from a beginners perspective.
The DocBook DTD is maintained by OASIS. These pages are aimed users who are already comfortable with SGML, and who want to learn DocBook.