The longer version ------------------ Background:Interoperability between email agents is becoming increasingly important as they diverge more and more in appearance (e.g. graphical vs. non-graphical), focus (e.g. speed vs. looks), and complexity (e.g. ability to parse badly formatted emails). The situation resembles the one on the web, which is at the point of being mended by XHTML and XSL.
Solution:I believe the same approach as for HTML should be taken for email: Define an XML Schema for valid emails, and implement extensions to existing email agents to make sure the emails they produce validate according to the Schema. Until properly implemented, user agents might include the XML email as a MIME attachment. The header values in the XeMaiL (everything home-brewed needs a nice nickname, don't you think :) would override the values in the "original" email.
By defining application-specific XSLT files as well, one could enable: - conversion from otherwise incompatible email readers, and - picking out only the bits _your_ email reader knows how to understand.When people get more used to write semantically instead of only graphically, one could use application-specific XSL-FO files to define how to display emails. That way users would have an easier time finding just the header information they are looking for, and power users could easily tweak the setting files themselves, as XML is rapidly becoming more used.
On top of all this, once the XSD, XSLT and XSL-FO files have been made, they will not be made obsolete for a long time.
Example 1:There exist three schemes for where to put the reply to a mail, namely before the mail being replied to, after it, or in between the contents. By using XML, one can clearly indicate which part of the email is being replied to in the different parts of the reply, and thus link them in an unambiguous way, leaving the disposition of the mail to the client. This way, nobody will have to read (much less format) something like the following:
---------------------
> How about two o'clock?
>
> > Any suggestions?
Sounds good
---------------------
Instead, the contents can be formatted thus:
<email id="55" answers="42">How about two o'clock?</email>
<email id="42">Any suggestions?</email>
<email id="13" answers="55">Sounds good</email>
... or thus:
<email id="13" answers="55">
<email id="55" answers="42">
<email id="42">Any suggestions?
</email>
How about two o'clock?
</email>
Sounds good
</email>
It will be relatively easy for any email client to sort these email in a
proper order before displaying the result, and line-breaking issues will
vanish.
Example 2:There exist different schemes for indicating threading in emails, and these are interpreted differently by email clients. A lot of persons use email clients which do not use the English "Re:" to indicate a reply, and this is also known to cause problems with threading correctly in some email clients. Some email clients even regard all emails with the same "Subject" value as belonging to the same thread. By demanding an identification tag to be included in each email, and a tag to indicate the ID of the email being answered, threading emails correctly would become almost trivial.
Example 3:Searching for an email or part of an email can be made simpler, as XML emails will contain a lot of explicit structural information. E.g., in a discussion group it would be rather easy to find every email that replied to only a certain part of another email. This can be particularly interesting if the first email is rather long, with many distinct topics which each branch into their own discussion.
Example 4:Signatures can be enclosed by a <signature> tag, making the error-prone (and rarely used) "dash dash space" solution obsolete, and making the process of building a relevant signature easy. On the client, this can make the creation and update of contact information easier, as the postal address, photograph URL, telephone numbers etc. can be extracted from an <address> block.
Attached is the first draft of an XML Schema to validate "XeMaiL". Please reply whether you are interested in adding support for XeMaiL to your email reader, and I will help you as much as I can.
I really hope XML email in some form or another will be standard soon, as the present situation leaves much to be desired...
(Much of) this email has also been sent to Microsoft Office support and Mozilla.
-- Victor Engmark
Attachment:
email.zip
Description: Zip archive