Some time ago, I wrote some quick-and-dirty greasemonkey javascripts to parse plain text bodies of mail messages and mark up things such as quotes, so you could collapse/expand them, colour quotes differently depending on depth, etc. As a result of that experience and countless flamewars about top vs. bottom posting, I've often thought that a markup language specifically designed for email was a good idea. top/bottom posting could be a presentation decision of the client; you could GPG-verify quoted mail; conventions like 'Re:' could be internationalized, again on the client side, etc.

This morning I discovered Mail Markup Language which is exactly that. Unfortunately, it appears to have some outright bizarre features. The RFC draft describing it is enormous, including a full XSLT description of the markup language (and not in an appendix either); a legal preface claiming that the entire thing was patent pending (and using a subset of MML would be considered patent infringement); it claimes to obsolete 1939, 3501, 5322, which are POP3, IMAP4r1, and Internet Message Format respectively.

You shouldn't judge a book by it's cover, but the fact their website displays awfully for me (epiphany 2.22.x) did prepare me somewhat for the zaniness that followed.

Comments

Atom
comment 1

Thank you for the criticism of my language. I have written this entirely on my own have been begging for criticism from anybody for a long time.

Please let me know which conventions you find bizarre. I am happy to defend my practices or change them if I am in error. I want this technology to be correct and vastly superior to HTML, so please let me know how and where I am wrong.

The RFC draft is long at 72 pages. To make it more legible I could move the code sections further down to just about the references section. In comparison RFC2616 for HTTP is nearly 160 pages on a subject far less verbose. The code sections are actually XSD that define the language and not XSLT, by the way.

I have not submitted this subject to the IETF because of its protection status. I am in the process of trying to find a remedy to this. I would prefer the technology remained protected and liberally licensed so that it becomes an enforceable standard rather than merely a recommendation where the fine print is largely ignored.

The specification does claim to obsolete POP3 and IMAP, but only because of their reliance upon RFC822 and its derivatives. This specification is in conflict with RFC822 as it defines conventions for formatting and defining header information.

The XHTML and CSS of my website are completely solid. Your browser is likely failing due to an experimental rendering engine or lack of support for the application/xhtml+xml mime type. For compatibility with IE I serve I dynamically detect support for application/xhtml+xml if the test fails I serve text/html using PHP logic. I do not that website looks flawless in these Windows browsers: IE6, IE7, IE8, Opera 9, FF2, FF3, Safari 3, Chrome, and FF2/3 in Linux. The Epiphany screenshot generated by totalvalidator.com shows that my website renders properly. I have not actually tested the website in Epiphany since it is a minor browser lacking a unique rendering engine.

There are changes I have in mind that I have not implemented yet:

  • Change the UTF-16 requirement to the more specific USC2-BE (big endian) form of UTF-16.
  • I have considered, but not fully decided, to rename the paragraph tag to block. Block is a more generic description of what a paragraph is and can then be used to describe other groups of statements whether they be captions, sub titles, or other groups of statements.
  • I need to adopt a future compatible convention based upon versioning. This is necessary so that a future version can be adopted the moment it is supported by software without conflict to prior versions. I have not fully decided on how this will work, but will likely be a policy requirement opposed to any convention in the schema.
  • I have considered methods to more directly support RDF, but have not chosen anything that will likely complicate the complexity of the language or its minimum requirements.

Please contact me directly via email for any suggestions. You can find my email address on my website where it is protect from spambots.

Austin Cheney,

✏ comment on this page (Help on commenting) ⏳