You are using a browser which doesn't fully support Cascading Style Sheets. This site will look much better in a browser that supports web standards, but its content is accessible to any browser or Internet device.
The language implementation
Let's go back to the parser. It was said that it implements the "PerlPoint base language definition to recognize paragraphs, macros, variables, tags, and so on". Does this mean that the complete language is implemented there? No, that's not the case. Instead of this, there is an important part left to the converter author to make the design as flexible as possible. This point is the definition of tags.
Tags are very converter specific. They usually reflect a feature of the target format or a special feature the converter author wants to provide.
Hyperlinks, for example, are essential if converting to HTML. They can be used in PDF as well. But if you are writing a converter to pure text, they might be useless. Or: one author wants to provide footnotes, while another one does not.
To implement all wished tags in the parser would make the converter framework very inflexible and hard to maintain. Such an approach could end up with a huge, difficult to maintain or even unusable tag library. All tag implementation details of all converters would need to be well coordinated. So that's no real alternative.
Instead of this, PerlPoint (or its base definition) only defines the syntax of a tag (and reserves a small set of tags implementing base features like tables or image integration). The definition of real tags, however, is a task of the several converters. So you are free to define all the tags you want, and you can modify this set without changes to the framework. A definition currently includes the tag name, option and body declarations, and controls how the parser handles tag occurences. It's even possible to hook into the parsers tag processing in various ways.
Tags are defined by Perl modules, for a simple reason: I looked for a way to make their usage as easy as possible. And what could be easier than to write something like
use PerlPoint::Tags::MyFormat;
? Hardly nothing.
But there are even more advantages. Defining tags by modules provides a simple way to combine definitions, to publish them in a central tag repository (CPAN) and to use them in various converters. PerlPoint even offers a way to say the parser "We do not implement the tags of target language SuperDooper, but please treat them as tags anywhere (we will ignore them in the backend running subsequently)." - which makes it easy to process one and the same source by numerous converters defining completely different tag sets.