Hector, > For people who have been in the mail business for a very long time, > that is a pretty broad claim.
It is a broad claim. I have seen several different attempts at creating a markup language for email, but none that fully function and support the complexity of SMTP protocol compared to the simplicity of the HTTP protocol. Such support would require conventions in an document capable of supporting multiple various authors uniquely such as an email thread without data cross-contamination from multiple contributions upon that document. SGML/XML do not provide this capability. When I was searching for prior art I found attempts at creating markup languages that made some progress towards defining content, but rarely did they make any attempt to absorb RFC 5322 definitions into structures represented by their language. I never saw any of these prior arts solve the problem of the prior paragraph. Most of the concepts represented of my language are not original, even the name of the language is not original, but still I had never seen anything that provided the benfits of markup to represent all currently practiced user-agent conventions of email. So while there have been attempts at creating markup language for email in the past none were either functional or solved the complexity of challenges represented by email that do not exist for the web. That does not mean my language is the best for the job, and I have never claimed that it is. Until something else comes along with its own unique solutions to common practices the language I wrote is the only thing I would refer to as a full markup language for email where all the prior attempts I have seen do not do the full job of the task. The only one thing I am absolutely certain about is that there is no standard for describing content in email. The closest such thing is a suggestive statement from RFC 822, which suggests that content be 7bit ANSI characters like the rest of the document. There is certainly no standard for use of whitespace definitions for visually preformatting content in emails for processing to user-agents, no standard for shoving HTML into an email, no markup language standard, or anything else. I do feel fairly confident that if there were a fully functional markup language that it would have some appeal commerically and so its existance would be commonly evident even if not in use. >From these conclusions and the hundreds of hours I spent doing research over the more than 18 months I took to actually write the language I feel pretty confident when I say my language is the first markup language for email. I may honestly be wrong this statement, but I don't think so. My language may not be the best choice for its job, but at the moment its the only choice. I would say if my language is of poor quality or fails at its job then pick another, but nobody else has volunteered their own personal time away from work or family to write such a thing. I don't believe my language should rest as the only one of its kind and I hope that I may see some alternatives. It is only from competing alternatives that I may truly know how flawed my attempt is. > A JSON format could be considered more optimized for wire-data, and > this does exist and done after a XML version was tested and pushed > aside. JSON is not a markup language or peer to XML, although a famed client-side evangelist I know of commonly claims otherwise. JSON is a serialized data storage mechanism and nothing more. XML is a meta-language, which is a language for creating languages. XML is commonly misused to act as a human readable data storage mechanism, but in my opinion that is a gross abuse of the technology in complete defiance of its purpose. JSON is not competition for XML and people who evangelize such likely do not understand what XML is. JSON is in competition with comma separated value format, but not XML. As a result it is a poorly informed response to a bad practice that allows for this reasoning of interchangability of JSON for XML. > In short, there is nothing new here. You may be entirely correct. The language I created does contain some patent pending features, so perhaps in three to five years after the US Patent and Trademark office concludes an investigation we will know for sure. Thank you, Austin
