//-----------------------------------------------------------------------------
|1WASD Documentation Processor |--| |'wasdoc.wasDOC| |
|^ For the first twenty-five years WASD documentation was largely maintained
using first the VAX, then DEC Document layered product (sold to Touch
Technologies, Inc.). With the demise of the TTI DEC Document a couple of
decades ago, it tenuously hanging on in legacy Alpha kits, without a port to
Itanium and certainly no prospect to x86-64, while there being no
vendor-supplied equivalent documentation system on VMS, or suggested else
elsewhere, then guess-what? Roll one's own, fit-for-purpose, CLI and CGI
document system. The browser having become ubiquitous in the couple of decades
since the birth of WASD and with HTML the lingua franca of markup languages
|--| use those!
//.............................................................................
|2YAML (Yet Another Markup Language)|
|0In WASD's inimitable style of course |'_smiley.\ |||
|^ No, not that one. This one |/is| a markup processor. The vertical bar
character is used to delimit markup tags and commonly the text they are applied
to. For example, this |*bold text| was formatted using |=\|*bold text\|| and
that explanation formatted using |=\|=\\\|*bold text\\\|\|||. Note the use of
the backslash character. It is all fairly straight-forward but more detail
shortly.
|^ If |'wasdoc.wasDOC| is intended for browsers then why not just write HTML or
use an HTML editor? Sure. But |'wasdoc.wasDOC| is more than just markup. It
is a processing system that integrates documents from multiple source files,
manages cross-referencing and table of content, is economical and concise in
its syntax while allowing a full(-ish) range of document capabilities, along
with presentation customisation using style sheets (CSS). All on VMS. All
using a preferred text editor.
|^ A knowledge of HTML and CSS is definitely |*not necessary| for authoring
using |'wasdoc.wasDOC| |-| but may help understand some design decisions |-|
and some understanding of CSS essential to customise the look and feel of a
document.
|^ Unreservedly, |'wasdoc.wasDOC| was designed and is intended for maintaining
general WASD documentation. Any other utility is incidental and secondary.
|0Other |'wasdoc.wasDOC| Advantages|
|^ Being a CGI application, quick and inexpensive when rendering, it is simple
to check editing changes as they are made. Just maintain a browser page on the
document and |/refresh||.
|^ The same CGI basis makes it a ready tool for creating dynamic documents.
External files, from anywhere the scripting account has access, can be
included. Other dynamic content, such as the current date/time |-|
|insert|time| |-| is also available.
|^ At the same time |'wasdoc.wasDOC| can be used on the command-line and the
rendered HTML output to a file (or files) allowing static documents to be
generated.
|^ Every browser's ability to print to PDF easily provides documents in this
format if required. Other document format conversion tools can be used to
render a static HTML document to |/whatever||.
|^ |*This document is a little overblown| for the following reasons; it
|*demonstrates| as many aspects of |'wasdoc.wasDOC| as possible, |*exercises|
those same aspects, and was employed as a |*development use case||.
|^ |*IMHO; It really is a delight to use.|
//.............................................................................
|2Deploying |'wasdoc.wasDOC||||
|^ Each document should be contained in its own directory. A document
comprises one or more |=..WASDOC| type files containing marked-up text. File
names beginning with an underscore are ignored.
|note|
|0=..WASDOC|
The |=..WASDOC| file type seemed an obvious choice.
|^- To have these recognised as plain-text, established WASD sites will need to
add |=..WASDOC| to global configuration.
|code|
# WASD_CONFIG_GLOBAL
|:::|
# -CONTENT TYPES-
|:::|
.VMS text/plain plain text
.WASDOC text/plain wasDOC Markup Language |insert|HERE|
|:::|
|!code|
|!note|
|^ A rendered document (HTML) is constructed by reading each of multiple
document files in directory order, creating an in-memory composite which is
then processed from beginning to end. Hence, the files
|mono|
1_INTRODUCTION.WASDOC
2_DETAIL.WASDOC
3_SOLUTION.WASDOC
9_CONCLUSION.WASDOC
|!mono|
generate a document that begins (suggested by file name) with an introduction,
some detail and a solution, and finishes up with a conclusion |-| all due to
each file being read and processed in order. Of course it could be confined to
a single file but this allows larger documents to have the source organised
into more managable chunks. There is no relationship between section numbering
and any numbering used in source file names. Document files, distinguished by
the file type (extension), may be mixed with other files in a directory.
|^ |*A blog| might be organised, with more recent entries listed before older,
by a set of files such as the following.
|mono|
1_OVERVIEW.WASDOC
5_996_2019FEB23.WASDOC
5_997_2019FEB09.WASDOC
5_998_2019JAN26.WASDOC
5_999_2019JAN12.WASDOC
9_POSTSCRIPT.WASDOC
|!mono|
Adding a new blog entry would be a matter creating a file with a name in the
"5" group, a number one less than the existing "latest" entry and then the
remaining file name, here suggested to be the actual date of the entry. Hence,
a file for a March 9th entry would be named |=5_995_2019MAR09.WASDOC| and the
first markup |=.\|hide\|| while the entry was edited |-| see |link|Document
Construction||.
|3Dynamic Document|
|9Apache server|
|9OSU server|
|^ These are documents which when accessed are generated and provided by a
(CGI) scripting application. The |=WASDOC.EXE| is placed into the server
scripting location and document directories mapped to become the
|=PATH_TRANSLATED| CGI variable provided to it. |'wasdoc.wasDOC| CGI is
suitable for use with VMS Apache, OSU and of course is a default component of
WASD. This document only considers WASD but the few principles readily
translate to the others. WASD CGIplus mapping may also be used.
|if|dynamic|
|*You are currently viewing a dynamic document|
(courtesy of |insert|cgi=server_software|).
|else|
|*You are currently viewing a static document.|
|endif|
|^ The simplest approach is just to provide the script with an already-mapped
file-system location. To process |'wasdoc.wasDOC||'s own documentation using
this approach the URL would be
|mono|
https://the.host.name|"\
/cgi-bin/wasdoc/wasd_root/src/wasdoc/doc/|| \†
|!mono|
|^+ \† |/may work or not depending on site configuarion|
|^ A document URI can be explicitly mapped to the document processor. This
allows the document to be "transparently" accessed (i.e. it's not immediately
obvious a script is being used).
|mono|
map /wasdoc/ /cgi-bin/wasdoc/wasd_root/src/wasdoc/doc/
|!mono|
The URL used to access that document would be
|mono|
https://the.host.name/wasdoc/
|!mono|
|*Note| that the |/directory| specification is parsed from the translated path
so anything following this is ignored. Continuing with the above mapping, all
the following are all equivalent and would return the rendered document from
|=WASD_ROOT:[SRC.WASDOC.DOC]| directory.
|mono|
https://the.host.name/wasdoc/
https://the.host.name/wasdoc/wasdoc.html
https://the.host.name/wasdoc/Fred+Flintstone
|!mono|
|0Large Document|
|^ A large document may be presented in major section "chunks". The advantage
is to have the client dealing with more manageable quantities of the document
in their browser at any one time rather than the whole thing, possibly over
many, many scrollable pages. Really just a personal preference. The content
remains the same. Note that a document is fully generated with each access,
even if only a portion is output to the client.
|^ This behaviour is controlled using the |=.\|set\|chunked=\|| document
setting.
|table|
|~_ |: Setting |: Behaviour
|~
|. |=\|set\|chunked=1\||
|. the document is always supplied chunked
|~
|. |=\|set\|chunked=0\||
|. chunking is determined by a numeric value trailing the URL
|~
|.
|. for example: |=./wasd_root/src/wasdoc/wasdoc/doc/000/|
|~
|. |=\|set\|chunked=-1\||
|. chunking is disabled
|!table|
|3Static Document|
|^ A static document is one produced at the command-line and then accessed as
any other HTML document.
|if|dynamic|
|*You are currently viewing a dynamic document.|
|else|
|*You are currently viewing a static document.|
|endif|
The |'wasdoc.wasDOC| executable can be activated
directly from the script location, or any other, using a foreign command or the
MCR utility.
|mono|
$ wasdoc == "$cgi_exe:wasdoc.exe"
|!mono|
If a file name is specified using the |=/output=| qualifier the generated HTML
is stored in that. else it is sent to SYS$OUTPUT.
|mono|
$ set default wasd_root:[src.wasdoc]
$ wasdoc [.doc] /output=[.doc]wasdoc.html
$ mcr cgi_exe:wasdoc.exe [.doc] /output=[.doc]wasdoc.html
|!mono|
Then the static content is available (continuing the example) via
|mono|
https://the.host.name|"\
/wasd_root/src/wasdoc/doc/wasdoc.html||
|!mono|
|0Multipart Document|
|^ As with dynamic documents, large static documents may be presented in major
section "chunks". This means the document is written as a series of files
with document navigation adjusting internal referencing to the required file.
Each file contains the document prologue (e.g. style data) and so is in some
sense a standalone sub-document requiring no further external resources. The
|/chunked| qualifier is used as with the following example.
|mono|
$ set default wasd_root:[src.wasdoc]
$ wasdoc [.doc] /output=[.doc]wasdoc.html /chunked
|!mono|
|^ This would produce a series of related files similar to the following:
|mono|
wasdoc.html
wasdoc000.html
wasdoc001.html
wasdoc002.html
wasdoc003.html
wasdoc004.html
|!mono|
|^ The unnumbered file is identical to the |=000| file and is provided for more
obvious access to the document. To suppress this file use |=./NOMAIN| and
to specify and alternate file name use |=\/MAIN=|/name||| qualifier.
|0Static Insight|
|^ |link|Document Insights| may also be added to static documents using the
|=./INSIGHT=|/.|||| qualifier. Using |=./INSIGHT| alone just lists
the document as it is processed.
//-----------------------------------------------------------------------------