Preparing a Course Outline

Steven J. Zeil

This document review the two documents that serve mainly to enable easy navigation of the website, the navigation bar and the outline.

It’s possible to use CoWeM to build a website without either of these special documents, with a few exceptions:

If you will have any documents prepared using the directory, modules, or topics formats, then you must have a navigation document.
If you will be preparing export packages for Blackboard (or, in future CoWeM version, other Learning Management Systems), you must have a navigation document.
If you will be preparing export packages for Blackboard (or, in future CoWeM version, other Learning Management Systems), and wish to have dates exported into the Calendar, you must have an outline document.

The navigation document supplies the navigation bar found to the left of directory pages like this one.

The navigation document must be in group Directory.
It must be the primary document for the document set must be named “navigation”. (In other words, it will be written in Directory/navigation/navigation.md.
It must be processed in the navigation format.

The document itself consists of a markdown document containing a simple item list of (usually) links to be placed into a navigation bar.

Here for example, is the navigation document for this website:

../../Directory/navigation/navigation.md


* [Outline](doc:outline)
* [Library](doc:library)
* [Example Sites](doc:examples)

Not much to it, is there? (The “doc:” links are examples of URL shortcuts, described in a later document.

To guarantee that this is processed in the proper format, the accompanying build.gradle file is

../../Directory/navigation/build.gradle

apply plugin: edu.odu.cs.cowem.Documents

 
documents {
    formats = ['navigation']
}

2 The Outline Document

The outline document is a Markdown document that presents a hierarchically organized collection of links to other documents in the website.

The outline document plays a special role when preparing export packages for Blackboard and other LMSs. For those purposes, it should be in group Directory, document set outline.

If desired, you could have multiple outlines presenting different organizations of the same website. But only Directory/outline/outline.md will be used to collect Calendar entries.

Despite it’s special nature, the outline document is, first and foremost, still a Markdown document. There are special formats for presenting an outline:

modules format yields a collapsible list format, like this.
topics format yields a tabular format, like this.

However, the outline can still be processed with the more basic format. In fact, preparing it as a 1_ may be a useful way to visualize the content as you are adding it. Here is the same outline in 1_ format.

2.1 Preparing the outline

2.1.1 Organization

Prepare the basic outline using the normal Markdown headers #, ##, ###, etc., to divide the outline as sections, subsections, etc.

If a section/subsection is going to be further subdivided, do not add any text in the enclosing level.

Example 1: Dividing the Outline into Sections

Title: CoWeM Outline
Author: v1.25.0, January 2026

# Getting Started

⋮ 

  

# Regular Languages

## Finite Automata

⋮ 

## Regular Expressions

⋮ 

## Properties of Regular Languages

⋮

2.1.2 Descriptive material

A section (or subsection or subsubsection or…) that is not further subdivided can have descriptive content. This material will appear in the modules view, but not the more compace topics view.

Example 2: Adding Descriptive Material

## Finite Automata

**Overview**
    
 A finite automaton (FA) is a mathematical model of a machine that
 switches among a limited number of different states each time it is
 fed a new piece of input.
    
    
 This is the most basic and the least powerful of the automata that we
 will examine this semester. It is, however, still capable of
 performing a variety of useful tasks, and its very simplicity makes
 it something that many people can work with intuitively.
    
      
**Objectives**

* Understand the basic definitions and concepts of finite
     automata and how they can be used to recognize languages.
       
* Construct FAs for some simple languages and determine what
     strings a given FA will accept. 
       
* Apply the pumping lemma to determine what languages can be
     recognized by finite automata.
       
* Modify a FA to minimize the number of states.
       
      
**Relevance**

    
 Despite their simplicity, finite automata can process a number of
 useful languages.  Because of their simplicity, programmers find FAs
 intuitive enough that they are often used to model high-level
 behaviors in large systems and in complicated programs (even though
 FAs are not powerful enough to model program behaviors in general.)

⋮ 

## Regular Expressions

**Overview**
    
 For every interesting group of automata, there is a corresponding set
 of languages that can be recognized by those automata. In this
 module, we examine the regular languages, the set of languages
 recognized by FAs. We look at regular expressions, a common notation
 for describing such languages, and one that should already be
 familiar to most students.
    
    
 Moving back and forth between FAs and their corresponding regular
 expressions is easier if we allow the FA to be in multiple states
 simultaneously. This leads us to the idea of non-determinism. We will
 distinguish between deterministic FAs (DFAs) and non-deterministic
 FAs (NFAs) and will explore how to convert from one to the other.
    
      
**Objectives**

* Read and write regular expressions for desired regular languages.
       
* Construct NFAs corresponding to a regular expression and
     regular expressions describing a given NFA.
       
* Convert NFAs to DFAs.
       
      
**Relevance**

    
 Regular expressions are pervasive in programming. They are a common
 tool in string searching, and students should recall their
 introduction in CS252 for that purpose. They are popular enough to be
 included in the standard libraries for both C++ and Java.
    
    
 Regular expressions are also widely employed in programming language
 compilers. The first phase of a typical compiler (the "scanner" or
 "lexical analyzer") compresses the input by reducing a string of
 characters to a string of tokens. Those tokens are typically
 recognized by a FA, which may have thousands of states. Compiler
 developers use automated tools to generate these FAs from a
 collection of regular expressions.


⋮

2.1.3 Activities

The core content of the outline is a list of activities in each of the undivided sections.

The activities are introduced by a horizontal rule in the section (typed in Markdown as a line containing three hyphens).

The activities are placed in ordered (numbered) lists. (Remember that Markdown will renumber the items, so the exact number you type are not important.) You can have multiple numbered lists in a section, separated by a simple a paragraph.

Here is an example of a complete section of a course outline , with multiple activities:

Example 3: Adding Activities


# Finite Automata

    
**Overview**
    
 A finite automaton (FA) is a mathematical model of a machine that
 switches among a limited number of different states each time it is
 fed a new piece of input.
    
    
 This is the most basic and the least powerful of the automata that we
 will examine this semester. It is, however, still capable of
 performing a variety of useful tasks, and its very simplicity makes
 it something that many people can work with intuitively.
    
      
**Objectives**

* Understand the basic definitions and concepts of finite
     automata and how they can be used to recognize languages.
       
* Construct FAs for some simple languages and determine what
     strings a given FA will accept. 
       
* Apply the pumping lemma to determine what languages can be
     recognized by finite automata.
       
* Modify a FA to minimize the number of states.
       
      
**Relevance**

    
 Despite their simplicity, finite automata can process a number of
 useful languages.  Because of their simplicity, programmers find FAs
 intuitive enough that they are often used to model high-level
 behaviors in large systems and in complicated programs (even though
 FAs are not powerful enough to model program behaviors in general.)
    
      
---


1. [ ](reading) Hopcroft, 2.1

2. [ ](lab) [JFlap: Finite State Automata](doc:fsa-jflap)
    
3. [ ](reading) Hopcroft, 2.2

4. [ ](lecture) [Finite State Automata](doc:fsa)

5. [ ](selfassess) FSAs (in Blackboard)

88. [ ](quiz) FSAs (in Blackboard) [2016-09-21](due:)

**At the end of the week**

1. [ ](survey) Take the module 2 feedback survey.

Each activity begins with a “fake” Markdown link [text](url).

For this fake link, the URL part designates the “kind” of activity. In the item above, one kind is “lecture”. This will be rendered using a small icon lecture-kind.png loaded from the website’s graphics/ directory.

In the modules format, if the text part of the fake link is blank (must have at least 1 blank character), then the presentation table (described below is checked to see if there is a standard prefix for that “kind”. If so, that prefix text is inserted. If the text part is non-blank, it overrides the standard prefix, e.g.,

5. [Take the self-assessment](self-assess) FSAs (in Blackboard)

After that, the rest of the item is treated as text in any CoWeM document. Many items will be links to documents, though references to off-line content such as textbook chapters will usually be in plain text.

The “quiz” item in the example above contains an example of a shortcut URL for recording a date. Dates recorded in this manner may be picked up in export packages for automatic inclusion in a calendar.

2.2 Special Sections

Following the main outline are one to three special sections that receive distinct processing in the modules and topics formats.

2.2.1 The Preamble

A section titled “Preamble” provides content that appears aobve the outline in either the modules or topics format.

It is actually a bug that this section must appear after the main outline sections. Ideally, you should be able to put it anywhere, but, currently, placing it above the outline causes incorrect section numbering in the outline itself.

The preamble is typically used to provide general navigation instructions to students entering the website.

Upcoming Events

If a metadata item

Calendar: yes

has been added to the top of the outline.md document, and if the “calendar” format has been generated for the outline, then an “Upcoming Events” section is displayed in the “modules” view immediately following the preamble.

2.2.2 The Postscript

A section titled “Postscript” provides content that appears below the outline in either the modules or topics format.

Typical content in the postscript might include a symbol key for the various kinds of activities listed in the main outline, or a “All times in this schedule are given in ”… time zone notice.

2.2.3 The Presentation

A final section, titled “Presentation” is a required element in the outline.

This section will contain two tables that provide formatting information used in the topics and modules formats, respectively.

The first table controls the number of columns in the topics view, the headings of those columns, and the arrangement of activities within those columns.

For example, this table,

Topics	Lecture Notes	Readings	Assignments & Other Events
topics	slides video lecture construct	text	quiz asst selfassess exam event

which can be typed in Markdown like this:

| Topics | Lecture Notes  | Readings | Assignments & Other Events |
|--------|----------------|----------|----------------------------|
| topics | slides lecture | text     | quiz asst selfassess exam  |

indicates that topics headings go into the first column, that slides and lecture activities appear in the second column, text activities in the third, and that various kinds of tests and assignments appear in the fourth column.

The second table controls wording inserted before activity items in the _modules view. For example, this table

Document Kind	Prefix
lecture	Read:
lab	In the lab:
event	Attend

which can be typed in Markdown as

| Document Kind | Prefix        |
|---------------|---------------|
| lecture       | Read:         |
| lab           | In the lab:   |
| event         | Attend        |

indicates that any lecture activity has the “Read:” appearing in front of it by default. These default prefixes are used only when no text is supplied when the activity kind is set. For example, the activities

1. [ ](lecture) Notes on getting started.
2. [Join](lecture) orientation session by net-conference

would appear in the modules listing as:

1. Read: Notes on getting started
2. Join orientation session by net-conference