There is even a defined ODF MIME type, application/vnd.oasis.opendocument.text-web, and associated file-name extension recommendation (.oth) for ODF text documents used as templates for HTML documents. There is no specific definition or schema for documents of that kind. My experience with what OpenOffice.org does with these is out of date. I confess to losing interest in the particular implementation.

It would be valuable for text-web documents to be defined well enough so these appealing applications could be achieved more smoothly. I could imagine .oth as an export case from web-based software. It might be even more valuable as an import-form for useful templates that would guide authors into expressing more web-like intentions, as Rob and others point out here.

The underspecified feature might be a fertile area to develop for an ODF-next beyond ODF 1.2.

PS: I believe that the equivalent of a forced within-paragraph line break does exist in ODF, although I don’t know what how it is supported in the various implementations. This matters, of course, like so many document-processor features, only if the poet uses it. I notice that I use the equivalent of tags a lot when I know I am making a web document, and I do it less often in making word-processing documents, though I know to do it and do so on occasion.

The poetry problem sounds interesting. The structure of poetry (lines and stanzas) doesn’t fit perfectly in ODF or HTML. In ODF you probably have each line in the stanza as a separate paragraph. And in HTML I usually see poetry done with each stanza as a paragraph, and each line ending in a br. Of course, you can make it look right in either format, but structurally it is a hack either way.

So a Word Press addon/plugin that imports ODF would be really useful to me. I was actually looking for any web based content management solution, but since I use Word Press for my own blog, and am used to it, that would be my preference.

We have implemented this is a variety of ways in our ICE project, and in our new desktop tool The Fascinator which uses ICE services to convert content from word processing formats to HTML.

An early publishing (ODF –> WP) plugin wouldn’t have to do a perfect job. It would need to implement a few basics in a standards-compliant way.
1) HTML/XHTML compliance, so wrap paragraphs in <p> tags and line break <br> between them.
2) Wrap the entire thing in a <div> and use CSS styles.
3) Find any headings and use the appropriate tags.
4) Find a way to enable the submitter to mark blockquotes, so they can be tagged.
5) Find a way to use accessibility-support within embedded images and links.
6) Possibly specify generic fonts in place of whatever the original document used.

The big thing that I see is that it would need to ship with good-enough functionality from the start, after which there might not be enough urgency to motivate continued improvement. It couldn’t be like early OCR software, where it was faster to re-type most documents than it was to scan –> OCR –> manually correct.

1) A plugin that adds a link to each table in a post (or to specified tables) that will download the table into an ODF spreadsheet document. Sometimes you see interesting data in a table and want to analyze it in a spreadsheet. Cut and paste sometimes works, but not always.

2) Conversely, ability to upload a spreadsheet, specify a range and convert that into a WP table.

3)Admin plugin to generate spreadsheet of summary data for all posts, title, date, category, number of comments, length, etc.

To the point about the difficulty of converting an arbitrary ODF document to HTML, this is something we’ve discussed in OASIS. One possible solution is to define a subset of ODF — the subset that maps perfectly to HTML/CSS2 — as an “ODF Web Profile”. If a desktop editor can save a document according to the ODF web profile, it would convert perfectly to HTML. The web profile would also be a reasonable output target for web-based editors.