The purpose of XHTML and CSS is two-fold.

Firstly, to allow the developer or designer to control the structure and layout of a site, and secondly to style or format content.

The structural bit is the responsibility of XHTML and the job of formatting and style falls to CSS.

The past several years have seen a lot of work in this area. From those efforts we have the emergence of standards based on CSS and the formalization of HTML as an application of XML. Combined, these technologies make a solid architecture for publication, they're terrible authoring or writing tools. They're just not simple enough for the job.

• The syntax is (necessarily) formal which results in a lot of overhead. Far too much for efficient writing.
• While complexity helps a markup language to be expressive and precise it leads to a laborious and error-prone writing experience.
• Syntax errors break the interpretation of the markup and detract from content.
• The burden of slogging through syntax discourages content creation.
• Mistakes in syntax with XHTML tend to cascade through documents in odd ways causing unexpected and often difficult to diagnose problems.
• Noisy markup distracts from and complicates writing and editing. Working with XHTML directly, it is not unusual for the amount of syntax to exceed the content itself!

For these reasons various lightweight markup languages have been developed for the purpose of presenting a minimal syntax intended to facilitate a more natural style of writing. These languages are typically implemented as both a syntax and a program capable of translating between its own grammar and XHTML.

These are intended to address many of the problems associated with writing on the web by:

• Simplifying plain-text formatted (source) documents so that they are as readable as possible, even without being converted.
• Encouraging the appropriate use of formatting to improve the readability of the resulting XHTML as displayed in the browser.
• Avoiding the problem of mistakes cascading through a document. Broken syntax simply does not translate and does not disturb the rest of the document.

The unofficial but preferred syntax for Ode is Markdown. There are a few alternatives, most prominent among them, Textile, which is another very nice implementation of a lightweight language.

So why Markdown?

Because more than the others, Markdown emphasizes readability of the plain-text document and that seems very much in agreement with Ode.

The other reason to choose Markdown is that it is written first in Perl and Ode is itself a Perl app.

Is this a big deal? Are we limited only to Perl when working with Ode?

No, but keeping as much of what is distributed with Ode in Perl will simplify things for new developers (more on development later).

I'll let the author of Markdown explain its advantages and raison d'être:

Markdown is a text-to-HTML conversion tool for web writers. Markdown allows you to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid XHTML (or HTML).

Thus, “Markdown” is two things: (1) a plain text formatting syntax; and (2) a software tool, written in Perl, that converts the plain text formatting to HTML. See the Syntax page for details pertaining to Markdown’s formatting syntax. You can try it out, right now, using the online Dingus.

The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. While Markdown’s syntax has been influenced by several existing text-to-HTML filters, the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.

Does that mean that you're stuck with Markdown?

No, Markdown is implemented as an addin. You're free to replace it with some other syntax using Ode's addin architecture (more on addins and development later).

It does mean that Markdown will always be distributed with Ode, that you should expect Markdown to work, and discussion of Markdown is considered relevant to this project.

In addition to Markdown, posts support HTML. Just keep in mind that they are contained within a larger page structure. So for example a body tag () should never find its way into your posts.

Next (Simple Content Management)

We've already hinted that Ode uses the filesystem as a content database, which of course is different than saying that there is no content database. Decades worth of effort speak to the effectiveness of filesystems at storing and organizing files and the data they contain. Modern filesystems are made to handle the rigors and requirements of modern operating systems and include numerous features designed to ensure the scalability, security, integrity, and availability of data. That's good enough for me.

Sure a filesystem is different than a relational database and we need to take advantage of its strengths rather than railing against its limitations. For example, filesystems are strongly hierarchical so we should take advantage of that organization.

Posts are organized hierarchically according to a topic-based categorization scheme. For example, the root of the weblog may contain any number of folders, which are categories, such as 'Technology', 'Politics', 'Music', 'School', etc. Each of these categories may contain any number of posts as well as subcategories (i.e. subdirectories). For example, 'School' may contain subdirectories for each of a number of different courses. Within each of these subcategories there may be more posts and additional categories.

As long as we are willing to organize posts hierarchically the advantages of using the file system as content database are numerous.

If you know how to manage and organize other types of files then you already know how to manage your Ode site (simple, right?). Even if you're new to computing, the skills you develop working with Ode are applicable to just about everything else you'll do with a computer.

That's just one aspect of simple content management. Here are some others:

Adding, editing, and deleting posts - your operating system's file manager and/or your editor are all you need.

Importing and exporting content - because posts are discrete text files, there are no distinct import/export procedures. With plain-text files you are in great shape to migrate your data to any other platform and if you are using something else now, at the very least you should be able to recover your content as text. You do not need to worry about being locked into Ode or losing access to your data.

Backing up and restoring - your posts are dicrete files which, as far as your operating system and backup routines are concerned, are no different than the other files on your computer. In fact the same thing goes for the rest of your Ode installation (not just your content). You can continue to use whatever backup mechanism you're using now. What's more your site can be backed up and restored incrementally at the level of a single post.

If your're not backing up your files currently, you really should start. In this case Ode doesn't complicate the decision about how to manage it or limit your range of options.

Permissions - Permissions for Ode are governed by the file and folder permissions and access controls dictated by your operating system. There's nothing special that you need to be conerned about. Even if you're not comfortable with permissions, for the vast majority of installations a simple permissions 'recipe', i.e. a straightforward set of rules is all you need. (See the documentation for more info.)

Interacting with a remote server - This is no more complicated than file transfer. Use sFTP/SSH/WebDAV/HTTP or any other file sharing protocol that works for you/your hosting provider/your environment.

File synchronization - Let's say that you want to run an instance of Ode locally on a laptop and also run a publically available server with the same content. For those times when you have your laptop but no internet access, you'd like to be able to create and edit posts locally. At other times, you may not have your laptop but you do have access to the internet from some other computer. You'd like to be able to sync the local and public sites.

This is the sort of thing that is very difficult to do with other packages and trivial with Ode. Taking advantage of best in class file synchonization utilities for your platform, you have the ability to mirror changes in either direction.

Well, that's probably enough of the simple content management shtick and there is so much more to discuss. Before moving on I want to point out that simple content management does not mean stupid content management. As simple as it is, we can do some clever things with Ode. Some examples:

In addition to the hierarchical categorization scheme that results naturally from the organization of files and directories, Ode is capable of interpreting date based requests.

For example:

(put in a table) sample.net/weblog/2007/ All posts created in 2007 sample.net/weblog/2007/01/ Posts from January 2007 sample.net/weblog/2007/01/02/ Only those posts dated January 2nd.

What's more we can combine the date and categorization schemes to limit posts in a given category by date, e.g.:

(put in a table) sample.net/weblog/Technology/Apple/MacOSX/2007/01/ Only posts in the MacOSX category created in January of 2007.

This scheme, which is ideal for date-based navigation and browsing, is built into Ode. Other schemes can be implemented using Ode's addin architecture. (More about addins later.)

Furthermore these date-based 'paths' make for perfect permalinks allowing you to reorganize your site at will without breaking links or violating one of the key tenants of the web, namely 'Cool URIs don't change'.

But that's not all. Because Ode sites are organized hierarchically (by date or category) they play nicely with search engines like Google. Just as simple posting means that we can write more efficiently, simple content management means that what we write can be shared and discovered by others more efficiently.

But we still haven't extracted all of the simple goodness.

Simple content management, in combination with Ode's themes, allows us to syndicate the entire site and every category separately. Maybe one of our visitors is interested in everything we write and another only in what we have to say about 'Technology', or just 'Technology/Apple'. Ode has the flexibility to do that, and without requiring that we make any special arrangements.

Next (Simple Themes)

Themes allow for customization of an Ode site.

The most remarkable thing about Ode's themes is that they're almost completely unremarkable. Themes are pure HTML and CSS. The entire page layout is described by a single file that looks like any other (X)HTML file to your text editor or web design and development app.

There is no need for you to change how you work with HTML/CSS for Ode. Repurposing your existing themes for use with Ode or reworking your Ode themes to work with any other package with a reasonable templating scheme should be relatively straightforward.

Here is the complete structure for the default theme at ode-is-simple.com

theme/ content_type.html date.html page.html logic.css

images/
    cod_header.png
    ode_tag.png
    ode_title.png
    xml_badge_bw_sml.png

Of these files, page.html and logic.css are almost entirely responsible for the look and layout of the site.

What's more, page.html starts with a doctype declaration

and ends with the closing html tag

Everything you know about HTML and CSS applies. There is nothing new to learn... no need to hop around among dozens of files inserting bits of HTML here and there being careful not to disturb sections of PHP and Javascript. Not only is this beneficial for users new to HTML and CSS, but experienced designers and developers can quickly implement an Ode theme, work out the kinks and then repurpose it for any other platform without rolling back the Ode specific elements (there aren't any).

Again simple doesn't mean limited. You can have any number of themes with Ode and switch among them at will. For example, you can display any page using any installed theme without changing the configuration of your site. Furthermore, you can apply a different default theme for any category. Themes associated with a category carry through to all subcategories but can be easily overridden.

So for example, you can establish a default theme for the entire site simply by associating one with the root category. If we want a consistent look for the entire site then that's all there is to it. However, if the 'Technology' and 'Music' categories should have different themes we can easily override the default for those two without affecting the rest of the site.

How does this work?

Each category can contain a 'Themes' directory. Each 'Themes' directory can contain any number of individual themes, each of which is contained in its own folder along with all of the associated files.

When a visitor requests an address, that request specifies one of either:

the root of the weblog (ode-is-simple.com/weblog/),

some subcategory (ode-is-simple.com/weblog/meta/),

or an individual post (ode-is-simple.com/weblog/meta/hello_world).

Ode determines which theme to use by starting at the most specific path to the request and working back toward the root. As soon as it finds a theme that matches the request (or a default if no specific theme was specified), it stops looking.

Themes are flexible enough that we can create any look we might want.

Bundled with Ode you will find one, two, and three column themes as well as several specialty themes including:

print theme text page theme (suitable for longer posts) RSS 2.0 theme presentation theme (compliant with the S5 standard)

All of these themes are standards compliant (XHTML 1.0 Strict).

What's more, care has been taken to insure that the themes are logically organized and as simple as possible. Working from these you should be able to create a site of your own design with a minimum amount of fuss.

Next (Simple Enhancements)