-
Notifications
You must be signed in to change notification settings - Fork 293
Document file specification
In the path towards a new documentation system, we need to settle on a specification of the document page format first. There's no such thing now, although there are some tests that check certain aspects of the documentation (and the rest of the files in the repository). Let's see what a documentation page really is.
- Content in Pod6 format.
- Document metadata
- Content metadata, including, but not limited to, indexes.
Let's see first what kinds of metadata we are using.
There are several pieces of metadata.
- A broad *topic", which is contained in the directory it occupies in the repository. There are
Language
,Type
andProgram
documents. - A narrow topic, which is implicit in the file name. For instance, some
Language
files that deal with transition from perl5 to 6 get special treatment when processed. - A section, which is conceptually the same as above, only it's processed by a different file and contained in the 00-POD-CONTROL file. This is essentially used to generate the
language.html
page. - A
tag
at the beginning of the file,=begin pod :tag<perl6>
. It's apparently unused, although it's a well-intentioned way of establishing a topic as in the first item above. - Title and subtitle.
- Class or role definition, if it's a class.
1 to 3 above are external to the file. 4 to 6 are internal. 2 and 3 are roughly the same, but they are dealt with in different ways. 2 and 4 are also roughly the same, but 4 is apparently unused and there's no specification of what values it should take and how to deal with them.
So, here's the spec proposal
- All metadata should be included as pod config in the
=begin pod
line. - The documents should have a topic with three possible values: Reference, Tutorial or Runtime (equivalent to the actual Type, Language and Runtime). All of these might have subtopics.
- Reference would have the possible values:
unit
(class, role),routine
(functions that are defined outside classes), orstatement
(whatever is not any of those, such asuse
orunit
). - Language will have as many subtopics as sections now.
- Reference would have the possible values:
- Title and subtitle will be compulsory.
- Reference documents will include a definition which will be compulsory and, if possible, checked against actual definition in Rakudo.
- Documentation will include no code that could produce side effects in the pre-compilation phase.
Internal metadata is good, and Pod6 does have a nice way of simply using it.