I have added a tutorial describing how to create an OpenDocument presentation; the url is http://langintro.com/odfdom_tutorials/

The 0.7 version of the ODFDOM – the OpenDocument API is now available for download.

I’ve also written some tutorials.

Enjoy.

Given the amount of discussion swirling around HTML 5, I had to put in my 2¢ worth. Here are my areas of concern:

Rulebooks

As I understand it, here’s the situation with the current markup languages:

HTML 4 is markup that conforms to the rules of SGML. Because there are optional closing tags, you need an external guide of some sort–specifically, a DTD–to find out if a document is valid.

XHTML 1.0 is the same set of elements and attributes, written to conform to the rules of XML. You can tell if a stand-alone document is well-formed because XML requires all opening tags to have closing tags. You still need some sort of external guide, written in Relax NG or XML Schema, to tell if the document is valid. (See Wikipedia for a discussion of well-formedness and validity.)

HTML 5 is a set of elements and attributes, written to conform to…well…according to the spec, “This specification defines an abstract language for describing documents and applications, and some APIs for interacting with in-memory representations of resources that use this language….There are various concrete syntaxes that can be used to transmit resources that use this abstract language, two of which are defined in this specification.” The two syntaxes are HTML 5 and XHTML 5.

The good news: I like the idea of an abstract language that can be transmitted in variety of formats; that’s a clever, flexible approach. The bad news: there is no rulebook. The FAQ says that the HTML 5 “syntax is inspired by the SGML syntax…, bits of XML…, and reality of deployed content on the Web.” There’s no DTD, so, in effect, the spec is the rulebook. This gives HTML 5 an “ad hoc” feel, no matter how well it may have been designed.

Things are better on the XHTML side; since it’s XML based, you can check documents for well-formedness, but there’s no schema for the XHTML serialization. I’d feel a lot better if such a schema were part of the specification.

Note: This doesn’t mean you can’t validate your documents; there is a validator, but its XHTML schema isn’t “official.”

Bad Markup

The good news: the HTML 5 specification tells exactly how to handle improperly nested elements or nesting of flow content inside of phrasing content (for example, <i><h1>Oops</h1></i>). This means that compliant browsers will give consistent results when handed bad markup.

The bad news: the specification doesn’t encourage sloppy markup, but by specifying that user agents will fix it, it doesn’t discourage bad markup, either. The penalty for bad markup is paid on the client side when the browser has to spend time repairing the markup.

HTML 5 vs. XHTML 5

The bad news: as I understand it, the plan is to move people to the HTML 5 syntax. The FAQ says that “the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML 1.0 to HTML5.” But I don’t want to go to the neither-fish-nor-fowl HTML 5 syntax.The good news: there is a drop-in replacement for the XML parser that will let me use tools like XSLT with HTML5, but given the widespread use of XML tools, why not encourage XHTML 5 instead?

The Janus Markup

Just as the mythological Janus looked both backwards and forwards, so does HTML 5. The good news: parts of HTML 5 are very forward-looking; specifically the <canvas> element, which is very open-ended. The bad news: many of the other new elements are designed to more efficiently represent the web as it is today. But in three years, when HTML 5 will be at candidate recommendation status, what will the web’s needs be, and what will a web site look like? (Consider: what did web sites look like three years ago?) See this site for an excellent discussion of forwards-looking versus backwards-looking specifications.

Summary

The good news: HTML 5 has once again sparked people’s interest the direction that markup should take. The bad news: I think HTML 5 is not the right direction. Your mileage may vary.

Here’s a NetBeans project that uses utility routines for creating number and currency styles from format strings. The source for the OdfNumberStyleExtra and OdfCurrencyStyleExtra classes is contained in the dist/lib/odf_convenience.jar file.

Someone on the odftoolkit.org forums wanted to know how to add images and tables to an ODP file. Here is an example. The file is a NetBeans project; go to the misc directory for the README.TXT instructions.

I did the rewrite of ODTransform so it would correctly transform a single member of an ODF package. I did this several weeks ago, and forgot where I put it.  I rewrote it a couple of nights ago, and then discover that the ODF Toolkit Project appears to have written something much like it with more options.

I’ve updated the List Style Builder to work with version 0.6.15 of the ODFDOM API. Instead of it creating a list style all by itself, you give it a <text:list-style> element and specifications of what the list should look like, and it builds the sub-elements for you.

Here’s the tarball.

I haven’t posted much lately, because the new semester at the school just started on Tuesday, and I’ve been busy (to say the least).

Also, I’m waiting for the ODF toolkit folks to release version 0.7, which may make some of the examples easier to write. (Yeah, I know I should try 0.6.11, but I’m busy!)

The ODTransform.java program that I wrote for the previous work doesn’t really do what I need it to do; it doesn’t copy over all the files that it doesn’t transform. Looks like it’s time for a rewrite. It’s late, though, and I will wait until tomorrow to do the rewrite.

Creating a <text:list-style> element with all of its child <text:list-level-style-number> (or -bullet) elements takes a lot of code.

The easyliststyle.py module lets you specify the level styles in a delimited string. Read the rest of this entry »