Mail Markup Language (MML) is a language to structure and describe generic content for human consumption sent over SMTP or a similar other method of transfer. The objective is to provide a vocabulary and structure that is semantic first and accessible second. The language allows for the integration of any other XML vocabulary as a namespace plugin.This documentation for Version 1.1 of Mail Markup Language is dated 25 December 2009 by Austin Cheney.

Distribution, reproduction, and transmission of this document, and the language contained herein, is unlimited WITHOUT owner or author consent.Mail Markup Language (MML) is the intellectual property (IP) of Sabre Inc (OWNER). MML contains features that are patent pending as well as additional features that are disclosed and unprotected novelties. Removal or omission of entire features, of specifically the language or its containing standard, may represent a conflict of IP unless approval for such removal is granted from an authorized agent of the OWNER. Version 1.1 of MML claims derivation from MML Version 1.0. Any protection or novelty implied or expressed by MML Version 1.0 must be applied upon Version 1.1 as a derivative work of equal scope, intention, and application as may be defined by the utility protection. include or import element child element element group child group attribute attribute group reusable complex type name of include or import element name element group name attribute name attribute group name name of reusable complex type element example processing requirements or RFC 2119 [34] language element's parent Some browsers parse character entity references as character literals when processed as XML with a stylesheet. This means reserved syntax characters to XML may be processed in some browsers even after they are properly escaped. In order to ensure a uniform syntax, semantics, and presentation "x" tags are written between the left angle bracket, <, and a tag's name in the documentation. For semantic consideration please ignore these "x" tags. The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 [34]. If an implementation, feature, or constraint does not satisfy a requirement level of MUST, MUST NOT, or REQUIRED for its respective statement, clause, phrase, or section that implementation, feature, or constraint MUST be considered failed. Under such a circumstance, known as conditional compliance, a MML document MUST NOT be transmitted. The ideal MML document will satisfy conditional compliance and SHOULD and SHOULD NOT conditions, known as unconditional compliance. tag A tag is a code command enclosed in angle brackets such as, "<strong>". Every tag exists as pairs of an opening tag and a closing tag. All closing tags are identical to their opening counter-part except that are preceded by a forward slash character, such as "</strong>". element The word "element" is synonymous and used interchangeably with the term "tag". It SHOULD be noted that the terms tag and element differ in XML Schema literature where "tag" refers to the syntactical delimiters and element name only so as to refer to the meta-data from the element name apart from the data it is describing while the term "element" refers to the opening tag, closing tag, and contents in between so as to represent a described data package. simple block A simple block is a tag that is capable of containing text and/or line-level tags. complex block A complex block is a tag that is capable of containing simple blocks or complex blocks, but is not capable of containing text. line-level tag Line-level tags are only capable of existing in simple blocks. Line-level tags cannot contain other tags. processor The term processor is to refer to any application that processes, interprets, or seeks to process a MML document. The term processor MAY typically refer to email client applications, but is not limited to such. The term "MML processor" is directly synonymous to the term "mail client" used by other related specifications. accessibility Accessibility is the degree of ease from which any human is equally capable of receiving data intended for human consumption from the desired document or request. Accessibility MAY refer to persons with a sensory disability, a motor disability, or software impairment. understandability Understandability is the degree of ability by which a technology can be learned and used by a person who has never seen or used the technology previously. Understandability also refers to the lack of effort necessary for an experienced user to consume and process the technology. Semantics Semantics refers to the degree of description provided by meta- data and syntax rules either statically or through nesting and hierarchal implementation thereof. The objective of semantics is to provide the most expansive description of data intended for human consumption without that description interfering with understandability during reading or writing. structure Structure refers to the effectual organization of data only as a result of well organized meta-data containers into a rigid hierarchy. session In the context of MML the term session only refers to an instance of communication, which is defined by the <session></session> tags. URI The abbreviation of URI is short for Uniform Resource Identifier. A URI is the address of a resource on a network or networks as defined by RFC 3986, addressed by RFC 3305, and supplemented by RFC 2368. The design philosophies for MML creation are listed in order of most significant to less relevant. Structure is the primary design consideration influencing MML. It is important that structure be the most important factor in the design of the language as all other design considerations are merely a result of the logic and conventions imposed by a well structured form.The primary difference between MML and other markup languages is that proper structure is mandatorily imposed upon a document author. This rigid inflexibility produces several profoundly significant benefits that exist inherently, which would otherwise merely be referred as best use. The cost that comes from such rigidness is the inability to put content absolutely anywhere in a document to circumvent any potential processing flaws of a processing software. Syntax in MML MUST be well-formed XML that conforms to the MML schema. Every tag in MML MUST exist as a pair of opening and closing tags. Syntax in MML is simple and always uniform.Tag names are English words and not abbreviations or shortcuts. This is critical to understandability. An abbreviation is a symbolic representation of its expanded value. Although it may be faster to write <p> instead of <paragraph> we are saving time and physical effort only at the expense of increase mental effort. If we know a <p> tag represents a paragraph then it becomes of a symbol of the word paragraph, which is a step of mental deduction.As humans we are rather so consumed by symbolic use that it seems a trivial effort to back out a single step of symbolic deduction. The savings become significantly more noticeable given the quantity of which meta-data often occurs in large mark up documents. The end result is that it is lesser mentally exhausting to read a document with descriptive and simple meta-data using complete words. Semantics are necessary for binding data, which is useful only to humans, and processing syntax, which is only useful to language processors. The objectives of semantic processing is for semantic processors to parse human supplied data and make decisions upon data that result in output relative to human decisions.MML was designed with consideration for applying semantics in the least specific manner. Tag names were created for understandability and not semantics. Any benefit received to semantics is purely consequential. There are two remedies to this intended lack of elaboration. Every tag in the <markup> section of MML is granted use of the role attribute. Hierarchal semantics are the primary unintended beneficiary of a rigid structure imposed upon the data. A combined use of the role attribute or the tag names and the hierarchal structure in which they exist is the second remedy for the lack of semantic elaboration.Even though conventions in MML were not created to directly benefit semantics the conventions of semantic languages, such as Resource Document Framework, were the primary influencing factor in creating the concepts and rules for imposing structure and tag hierarchy. It is an important factor that all persons are equally capable of accessing, using, and understanding documents defined as MML. Accessibility is a lesser important design factor as many concerns of accessibility are addressed by proper use of semantics, understandability, and usability. Usability is primarily a result of interaction of the data, which exceeds the scope of this document. Presentation is perhaps the least concern of all design factors influencing MML. All presentation will exist in either an external stylesheet(s) or the default presentational conventions supplied by the MML processor.This version of MML only recognizes Cascading Style Sheets and Extensible Stylesheet Language as presentation languages. The degree of processing compliance afforded to those languages and which versions are process-able are processor specific concerns, which exceed the scope of this document. MML processors SHOULD make no assumption that there is an implied default presentation that any tag, element, or concept must adhere to. While security is always important it is of trivial concern to the describing of data, which is why security is a consideration for the design of MML, but is lowest priority. Much of the effort in assuring MML data remains confidential and maintains integrity rests on the processing of the MML processor, the security of the protocols used to transport the data, and the general security practices of document authors.Nonrepudiation is the most important security consideration, except perhaps for encryption, concerning email. The job of nonrepudiation rests most prominently with proper storage practices of documents by users and time/date stamps imposed by email processors on the arrival of mail documents. MML does contribute to nonrepudiation by requiring a timestamp in a manner beyond user control.MML does provide a method for specifying implementation of public key distribution to facilitate encryption. Please refer to the public-key attribute for more information.MML also implements a description scheme for every attached asset using MIME to identify various types of media. Media can only be executed according to the specified MIME type value. The intent is that a file that looks like a graphic and has the file extension of a a graphic may actually be a malicious executable program, but if it has a specified MIME type of a graphic format it can only open as a graphic or it MUST NOT be processed. In order to advance the functionality of this technology it is necessary to incorporate use of prior existing standards. MML is written in W3C XML Schema, which is written XML. As a result MML code is case sensitive. This means all tag names MUST be lower case. XML also requires that all attribute values MUST be quoted, tags MUST be properly nested, and every opening tag MUST have a corresponding closing tag. Failure to adhere to these syntax rules will result in the document not validating, which will cause it to not send. XForms is the only form method specified in MML. Where XForms usage is allowed by the MML schema it MUST be used in accordance with the XForms schema: http://www.w3.org/Markup/Forms/2002/XForms-Schema.xsd. Processors MUST use XForms version 1.1 to be compliant with this version of MML. The standards specification Accessible Rich Internet Applications, WAI-ARIA, is not included into this version of MML due to the specification not being formalized at the time of this writing. WAI-ARIA is intended to be implemented in future versions of MML. For more information please see: http://www.w3c.org/WAI/ Resource Document Framework, RDF, is not an included technology of this specification, however RDF did significantly influence design patterns of MML. RDF implementation MAY occur as a server-side feature, an optional client specific feature, or a MML processor behavior feature. RDF implementation MUST NOT interfere with conventions, syntax, data, or meta-data supplied in the document directly. This is necessary so that a MML document maintains a pre-RDF existence for distribution to other users that may not be capable of processing RDF. For more information please see: http://www.w3c.org/RDF/ This version of MML recognizes only Cascading Style Sheets (CSS) and Extensible Stylesheets Language (XSL) as stylesheet languages. MML imposes no requirement to support stylesheets. If a MML processor does attempt to support a particular stylesheet it SHOULD state what version is supported and SHOULD fully support that version according to its specification. For more information on CSS please see: http://www.w3.org/Style/CSS/ For more information on XSL please see: http://www.w3.org/Style/XSL/ MML does not support any scripting or behavior technologies. This version of MML does not provide a solution to likely cross-site scripting vulnerabilities, breaches of non-repudiation, or interference to the integrity of the data that may result from the execution of scripting at the user agent software. Standards and technologies that wish to dynamically alter or access a MML document SHOULD do so only using XPath or DOM expressions and MUST NOT violate the document segragation imposed by processing the <session> element. MML supports the transfer of public keys by directly embedding the hash value of the public key into the document. MML provides no support for specifications regarding encryption, data transport, or confidentiality. These are application specific and protocol features that exceed the scope of this document. Please see the <public-key> tag for more information on MML implementation. For PKI specifications please see: http://www.rsa.com/rsalabs/pkcs/ Uniform Resource Identifier (URI) is a representation of an address to an external asset. MML requires the use of URIs to specify locations of any object or stylesheet. Aside from text the only data that MAY be included directly into the document are public key hashes. For additional information please refer to RFC 3305. Multipurpose Internet Mail Extensions (MIME) is specification designed to support an expanded character set beyond the basic 7-bit ASCII natively supported by SMTP. For more information on the MIME specification please refer to RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289, and RFC 2077. The role of a processor of MML is to conform to the following specified requirements. Processors of MML are, however, allowed certain freedoms from presumption that are also specified. MML processors are encouraged to test the limits of innovation. Diversity, usability, and customization are necessary results of competition. The intent of subsection Processor Requirements and Constraints is to impose requirements upon MML processors to ensure the integrity of the language. The intent of subsection Processor Allowances is to illustrate some areas where MML processor vendors are free to explore without fear of violating this specification. The intent of imposing requirements and constraints unto the processor is to provide a uniform existence for data, meta-data, and syntax rules contained in a MML document not at the burden of a document author. It is absolutely essential that a MML document MUST validate against the MML schema prior to transmission. If a MML document does not validate it MUST NOT be transmitted as email across any email specific protocol or Hyper Text Transfer Protocol. A MML processor is not REQUIRED to process any malformed or invalid MML document.It is not invalid, according to some schema validators, for a session author to include empty tags, also known as nil content, such as <style></style>. It is, however, invalid to include nil content elements, in accordance with the XML Schema standard, without explicitly stating the XSI:nil="true" attribute. Empty tags MUST be removed by the MML processor during validation. Every tag SHOULD contain text, other tags, or both if so allowed. A MML processor MUST create RFC 5322 conformant mail headers for backwards compatibility. MML aware clients/servers MUST remove this header data and instead rely only upon the header information specified within the MML code. This is necessary to ensure seamless transactions across the SMTP protocol to clients not prepared to receive MML. This header data MUST be created after document validation for transport and prior to the document being transported. MML processors MUST process each session of a MML document separately. This means a stylesheet specified in one particular session MUST NOT be processed in another session on the same document. For instance a background specified, via stylesheet, in one session cannot exist as a background in any other session unless so specified in each other session even if in the same document.A MML processor SHOULD allow session authors to alter the presentation of all elements and content in a session even if those elements or content exist outside the message body. This is not a requirement because MML processors MAY choose to display the session header information only in their application shell opposed to text. All prior sessions received in a MML document MUST be preserved verbatim, including whitespace and presentation. Decisions upon prior sessions MUST NOT be allowed except whether external assets MAY be processed. A MML processor SHOULD take steps to prevent prior sessions from manual alteration by a session author. The character set for this version of MML MUST be UTF-16BE. The value of the time-stamp attribute MUST be written by the MML processor between the moment the session author submits the document for transmission and the validation by the MML processor. The MML processor MUST write over any value supplied by the author with the correct value. The value MUST be based upon the local system clock. MML processors MUST set a standard timeout for any URI that is referenced in a MML document. The length of that timeout MAY be determined by the MML processor. User adjustment to the timeout length setting of the MML processor is OPTIONAL. If a MML processor cannot resolve any resource at its specified URI timeout that resource MUST fail. Every object, stylesheet, or other external resource MUST be processed strictly according to its specified MIME type. If a resource does not match its associated MIME type it MUST NOT be executed. Processing of any external resource to a MML document by a MML processor is OPTIONAL. External assets, such as stylesheets or objects, MUST be cacheable by the MML processor. Caching significantly improves performance by reducing the demand for bandwidth and allowing access to content even when offline. Options, configuration, and implementation MUST exist entirely at the discretion of the MML processor. MML processors MUST locally contain all required code components necessary to process and validate a MML document according to the MML schema. These components can be obtained from the following list: http://mailmarkup.org/mail.xsdhttp://www.w3.org/MarkUp/Forms/2002/XForms-Schema.xsdhttp://www.w3.org/MarkUp/SCHEMA/xml-events-attribs-1.xsdhttp://www.w3.org/2001/XMLSchema.xsdhttp://www.w3.org/2001/03/xml.xsdhttp://www.w3.org/2001/XMLSchema.dtdhttp://www.w3.org/2001/datatypes.dtdhttp://mailmarkup.org/mime.xsd MML processors MUST NOT require the use of a network or internet connection to process or validate a MML document. A MML processor's list of acceptable MIME types MUST exist as a local schema file. This file MUST be available for editing by either an administrator or common user. Adding new MIME types to the list will likely result in a failure to process outside an internal network. Removing MIME types from the list MUST result in a failure to process media of those types. By default the values in the MIME catalogue file will be every IANA registered type. The <from> and <reply-to> tags are REQUIRED tags, so the tags will exist even if their content is null. If their content is null the MML processor MUST supply default values of the session author's email address. This MML processor supplied default content MUST be supplied by the MML processor between the moment the session author submits the document for transmission and the REQUIRED validation by the MML processor. The default value for the <from> tag MUST be the address represented by the author. The default value for the <reply-to> tag MUST match the default value of the <from> tag.Session authors are allowed to specify content for these elements to hide their email address. The benefit is to customize how other session authors can control direct traffic, such as reply and forward traffic, back to their email address. It is important to understand the actual traffic benefit of these fields as they offer absolutely no security advantage. MML processors MUST NOT use, process, or regulate the <from> or <reply-to> tags for any intent related to security. Email transmission protocols operate in unencrypted plain-text by default, which is where any user can easily find any address or identity information. Attachments to the current session MUST be sent with the actual MML document. Attachment persistence is OPTIONAL to the MML processor vendor. Attachment persistence refers to whether or not attachments will continue to be sent with the MML document after the document session arrives at its originally intended destination(s). A MML processor SHOULD allow users to choose to allow persistence. Attachments MUST be processed only according to their specified type. Processing of attachments by the MML processor is OPTIONAL. The type specified for <collection-type> MUST represent every file in that respective <collection>. If the <collection-type> tag is not present the files located in the collection MUST NOT be executable from the MML processor, MML document, or any other mail service software. Content provided in <plain-text> MUST be processed as plain text characters and/or whitespace only. Code MUST NOT be processed, rendered, or transformed in this tag. XML reserved syntax characters MUST be properly escaped automatically by the MML processor or validation SHOULD expect to fail. The value supplied by the style attribute is defined in the MML schema as lowercase alpha characters, uppercase alpha characters, and/or numbers plus a colon character (:) plus lowercase alpha characters, uppercase alpha characters, and/or numbers. The characters supplied prior to the colon MUST represent the value supplied in a <stylesheet-namespace> element of the same session. The value supplied after the colon SHOULD represent a reusable processing declaration defined inside the stylesheet, such as a CSS class. An example of a supplied value: "namespaceName:CSSclass09".Stylesheet processing is OPTIONAL. If the noted stylesheet cannot be resolved or if the value supplied by the style attribute is either malformed or fails to match a stylesheet of the same session this attribute MUST NOT be processed. Text MUST be processed in accordance with the defined values for the four internationalization attributes. For processing descriptions please refer to these features: direction Attributeorientation Attributewrap Attributesection-language Attribute Failure to process internationalization attributes according to their definition MUST result in conditional compliance failure. The xmlns attribute is not defined in this specification. It is defined in the specification for Namespaces in XML 1.0. It is considered an included technology by virtue of the xml.xsd schema that is imported into the XMLSchema.xsd schema that is imported into the mail.xsd that defines MML. Use of the xmlns attribute MUST be allowed on the <session> element and any element contained by the <session> element in accordance with XML processing guidance defined by XML and Namespace standards. The refer attribute MUST NOT be allowed to reference id values outside the specific <markup> element containing the refer attribute. MIME types MUST be stored in the mime.xsd document, which is merely a catalogue of all IANA registered MIME types at the time of this writing. The information stored in mime.xsd is used in the MML schema through the use of the "mime-type" schema complex type.Elements based upon the "mime-type" element type are allowed only one of nine possible child elements. These child elements each represent a IANA registered content type. The values for those child elements MUST be a MIME sub-type that exists in the local mime.xsd file. The child elements are: <application><audio><example><image><message><model><multipart><text><video> This document does not exist to define the role of MML processors for features that exceed the scope of this document. This section only serves to dispel assumptions and specify certain freedoms allowed to MML processors, which are not be allowed to processors of other markup languages. This specification does not make any statements regarding presentation of the language. This means a MML processor is free to determine the default presentation for tags and objects. This default presentation MAY apply to any or all parts of a MML document. This means that presentation provided from a MML processor fits a wider scope than presentation specified by a MML author since any MML author can only specify presentation by use of an external stylesheet and stylesheet processing is limited to its session of the document.MML processor default presentation MUST be lower priority than presentation defined in a stylesheet. If a conflict in presentation arises between the default and a stylesheet the presentation specified by the stylesheet MUST dominate even in regards to cascading. This means a MML processor determines font size, color, font, and so on until so specified by a stylesheet. A MML processor determines, by default, whether complex and simple blocks impose a line break, wrap, float, or so on. A MML processor SHOULD allow a user to customize or alter its default presentation. This specification will not mandate customization, however, accessibility concerns SHOULD be considered for changing text size, turning off stylesheets, and replacing objects with their respective text content. This specification states no directive for behaviors or controls upon the data or the usability thereof. There is no convention for allowing client-side scripting in MML and any scripting that does exist MUST be processed as plain text content. MML processors SHOULD allow behaviors that increase accessibility more importantly than usability.Section Resource Document Framework states that RDF is not an included technology in this specification and MUST NOT interfere with conventions, syntax, data, or meta-data supplied in the document directly. What it does not say is that semantic technologies MAY be used to auto-fill many areas of MML based upon a user's data habits. Semantic technologies MAY also be used for searching, data sorting, or other processing features to the data defined by the MML document. Those semantic technologies MUST NOT, however, alter the contents of the MML document. MML processors MUST be capable of processing the full MML specification. MML processors MAY allow processing of or definition of elements or conventions not defined by this MML specification. Such elaborations MUST NOT interfere, limit, constrain, remove, or disable any aspect of the MML specification. Any elaboration, element, or convention not defined by this MML specification is OPTIONAL of MML processors. It is important to determine if there is any interference to existing communication protocols imposed by the formal structuring of data. This section intends to determine if there are any incompatibilities with existing protocol standards and not whether existing services fail. It is anticipated there will likely be natural incompatibilities with existing technology that MAY perform sophisticated processing and relay of data across a network without expectation to uniformity to the definitions imposed upon that data.Application oriented concerns not defined by this specification, especially vender-specific concerns, exceed the scope of this specification. If the standard imposed by this specification is not incompatible with existing standards it will be necessary for software vendors to modify their applications to ensure support of this technology without service interference.This section will explore considerations for the gathering of data from a MML document necessary to conduct transportation of the document. This section is subdivided by mail distribution protocol. SMTP [RFC5321] is the backbone protocol of email distribution. This protocol is responsible for sending all email and often for receiving mail. In order to be compatible to the requirements of RFC 5321 (SMTP) RFC 5322 (Format) MUST be obsolete by this document. This specification seeks to replace RFC 5322 as the standard method for describing data in email.RFC 5321 sets specific methods and requirements for the use of header fields from a mail document for use in defining transport and response necessary information. There is no guidance specified for precise movement of header information from a document to protocol use under any particular circumstances. The result is that MML processors MUST extract header information from the concerned header tags in a way that it deems most efficient and convenient to its logic so long as transport can be achieved in accordance with RFC 5321 and without harm to the document. Please see section 3. The SMTP Procedures: An Overview and Appendix B. Generating SMTP Commands from RFC 822 Headers from RFC 5321 for specific details. POP3 [RFC1939] is incompatible with this specification due its section 11. Message Format. RFC 5322 is obsoleted by this document. POP3 is therefore incompatible by direct result of the following statement:"All messages transmitted during a POP3 session are assumed to conform to the standard for the format of Internet text messages [RFC822]." - It is important to note that RFC 822 is obsoleted by RFC 5322.The result is that RFC 1939 MUST be obsolete. If POP is to remain a standard it MUST be revised to either expect header information in MML specific format or be format non-specific. IMAP [RFC3501] is inherently dependant on formatting specified by RFC 5322, and so it MUST be rendered obsolete as a result. At this time of this writing Web Mail is inherently dependant upon POP3 and/or IMAP protocols. Since these protocols are rendered obsolete by this specification it can be assumed that MML is incompatible with web mail as it exists during the time of this writing.In order for MML to be compatible with web mail the following conditions, beyond protocol compatibility, MUST be enforced: he containing document, such as a page of Extensible Hypertext Markup Language ((X)HTML), MUST be served, processed, and rendered as a subset of XML.The MML processor specific requirements specified in section 4. Processor Roles are REQUIRED. Components of the containing document, such as a page of (X)HTML, MUST NOT mix or interfere with the MML code. MML, and its subsets; if any, MUST exist as a preserved code island.MML MUST be sent without interference or supplication to its code or structure from its containing document, as a page of (X)HTML.Scripting that exists or is allowed by a containing document, such as a page of (X)HTML, MUST NOT be allowed to execute against the code, content, or structure imposed by the MML code island. MML presentation requirements MUST be enforced. Presentation from the containing document, such as a page of (X)HTML, MUST NOT act upon or interfere with presentation imposed by MML referenced stylesheets. The containing page MAY establish lowest priority default presentation exactly as a MML processor MAY do so. The containing document MUST be served only to the authorized user through an encrypted transmission.An XML compliant web browser SHOULD be capable of processing, presenting, and transmitting a MML document without any need for a containing document or any use of HTML or reformulation thereof. XForms-Schema.xsd The schema for XForms is a schema import from http://www.w3.org/MarkUp/Forms/2002/XForms-Schema.xsd with a declared namespace of http://www.w3.org/2002/xforms. By default this file SHOULD be imported from a local relative path at the user agent software default. mime.xsd The mime schema catalogue is a schema include from http://mailmarkup.org/mime.xsd but SHOULD be included from a local relative path at the user agent software default. mailThe root element of MML is the tag <mail>. The root tag is only capable of containing <session> elements.<mail mail-type="application/mail+xml" version="1.1">↔</mail> session (may occur more than once) mail-type (required) version (required) xmlns:xfm (required) - an external requirement not provided by the syntax of the schema xmlns:xs (required) - an external requirement not provided by the syntax of the schema mail-typeAttribute mail-type is REQUIRED with a fixed value of "application/mail+xml". This attribute defines the media processing specification for a Mail Markup Language document as a MIME type.mail-type="application/mail+xml" versionAttribute version is REQUIRED with a fixed value of "1.1". This attribute defines the revision of the Mail Markup Language specification.version="1.1" sessionElement session is the only child of root element <mail>. The session tag contains all information to represent an instance of communication including markup and header information.The session tag allows three methods of communicating the message body. The source method allows a session author to send an external resource as the message body. The plain-text method allows a session author to communicate using only text characters and whitespace. The markup method allows a section author to use MML markup to describe the data.<session time-stamp="2009-12-25T13:29:59.17+4:30" language="en">↔</session> address (required) attachments (optional) subject (required) presentation (optional) source (required choice between source, plain-text, and markup) plain-text (required choice between source, plain-text, and markup) markup (required choice between source, plain-text, and markup) time-stamp (required) language (optional, default value is "en") time-stamp Attribute time-stamp and its value MUST be written by the MML processor between the moment the session author submits the document for transmission and the validation by the MML processor. The MML processor MUST write over any value supplied by the author with the correct value. The value MUST be based upon the local system clock.time-stamp="2009-12-25T16:47:32.52+4:30" languageAttribute language is an OPTIONAL attribute that allows a session author to describe the majority language of the session using values appropriate to the XML Schema language data type. The default value is "en" if none is specified. Mail client software SHOULD allow a user to specify a default value for the language attribute.language="en" addressElement address is a REQUIRED child of <session>. This is a high level tag designed to store child tags containing email address information.Child elements <to>, <copy>, <blind-copy>, and <from> are formed of complex type "agent".<address>↔</address> to (required and may occur more than once) copy (optional and may occur more than once) blind-copy (optional and may occur more than once) from (required) reply-to (required) reply-toElement reply-to is a REQUIRED child of <address>. It is identical to the <from> tag except that it may contain either a valid email address or a value of no-reply. This tag is used to set an address for deflecting email replys from the address used to send the email or to establish an alternate destination for receiving replies.<reply-to>no-reply</reply-to> alias (optional) public-key (optional) agentComplex type agent represents the construct of elements <to>, <copy>, <blind-copy>, and <from>. These elements store only the value of a properly formed email address. They may contain the optional attributes of alias and public-key. alias (optional) public-key (optional) aliasAttribute alias is an OPTIONAL member of complex group agent and an OPTIONAL child of element <reply-to>. The alias is intended to contain a value more human readable representation of an email address, such as a person's name.alias="Online Travel Agency Customer Service" public-keyAttribute public-key is an OPTIONAL member of complex group agent and an OPTIONAL child of element <reply-to>. The public-key attribute is intended to store text characters that represent a hash function name and a hashed public-key for asymmetric encryption. These two values MUST be separated by a colon only with the hashed key value after the colon. The hash function name MUST be uppercase alpha or numbers only.public-key="SHA256:5DBDDF911F9E565299428E948A92EA5D1943C4099DB883CC4491CB32CC757DE8" attachmentsElement attachments is an OPTIONAL child of <session>. This element is a high level tag for specifying file(s) for transfer with the document. Attached files are not intended for processing in the message body.<attachments>↔</attachments> collection (required choice of either collection or file) file (required choice of either collection or file) collectionElement collection is a REQUIRED choice between it and element <file> of <attachments>. This is intended to serve as a collection of multiple files of the same specified type.<collection>↔</collection> collection-name (required) collection-file (required and may occur more than once) collection-type (required) collection-description (required) collection-nameElement collection-name is a REQUIRED child of <collection>. This element may contain a token string value. The intent of this tag is to provide a simple name or label for the attached collection.<collection-name>SpinBaldak_26Dec2009</collection-name> collection-fileElement collection-file is a REQUIRED child of <collection>. This element stores the file name of a particular file in a collection. This tag MUST exist for each file that is to exist in the collection. Only non-colonized name values are accepted with a period separated file extension.<collection-file>ChamanAtNight.jpg</collection-file> collection-typeElement collection-type is an OPTIONAL child of <collection>. This element is formed of complex type mime-type, which is defined in the mime.xsd schema. If this tag is not present the files present in the collection MUST NOT be processed by the MML processor.<collection-type><image>jpeg</image></collection-type> collection-descriptionElement collection-description is a REQUIRED child of <collection>. This element exists to specify a text description of the collection. The content for this tag MAY represent examples of intended use, explanations, file ownership, origin information, and so forth.<collection-description>This photo collection represents my visit to Spin Baldak.</collection-description> fileElement file is a REQUIRED choice between it and element <collection> of <attachements>. This element is intended to serve as a single attached file.<file>↔</file> file-name (required) file-type (required) file-description (required) file-nameElement file-name is a REQUIRED child of <file>. The value for this tag MUST be a non-colonized name with a period separated file extension. This tag represents the name of the file being attached.<file-name>FOB_SpinBaldak_library.psd</file-name> file-typeElement file-type is a REQUIRED child of <file>. This element is of type mime-type, which is defined in the mime.xsd schema. The attached file MUST be processed according to the value supplied in this tag, or it MUST NOT be processed by a MML processor. Processing of attached files by MML processors is OPTIONAL.<file-type><image>vnd.adobe.photoshop</image></file-type> file-descriptionElement file-description is a REQUIRED child of <file>. This tag allows a session author to enter any normalized string value that describes the attached file.<file-description>A digital painting in Photoshop PSD format illustrating my brief experience in the library at FOB Spin Baldak.</file-description> subjectElement subject is a REQUIRED child of <session>. This tag stores a normalized string value that represents the email's subject line.<subject>A tour of Afghanistan outside Spin Baldak and Qalat.</subject> presentationElement presentation is an OPTIONAL child of <session> All presentation not supplied by default from the MML processor software is referenced from this element's child elements.<presentation>↔</presentation> stylesheet (required and may occur more than once) stylesheetElement stylesheet is a REQUIRED child of <presentation>. This tag MUST have a URI of valid syntax as its value.<stylesheet style-namespace="KAF" style-type="text/css" media="print">http://mailmarkup.org/example_stylesheet.css</stylesheet> style-namespace (required) style-type (required) media (optional) style-typeAttribute style-type is a REQUIRED attribute of <stylesheet>. This attribute accepts only one of two values: application/xslt+xmltext/cssstyle-type="text/css" style-namespaceAttribute style-namespace is a REQUIRED attribute of <stylesheet>. The value for this attribute serves as unique named prefix for stylesheet declarations from this stylesheet. This attribute MUST follow the same syntax and processing requirements as the attribute id. This attribute value MUST be unique within the scope of the <session> and SHALL NOT be unique in the entirety of a MML document. The prefix is REQUIRED for stylesheet references using the "style" attribute that is available to elements in the <markup> section of the session.style-namespace="global" mediaAttribute media is an OPTIONAL attribute of <stylesheet>. The default value for this attribute is "screen" and this default value MUST be presumed if the attribute is absent. This list of accepted values exists in conformance to the list defined by the W3C: http://www.w3.org/TR/CSS2/media.html allauralbrailleembossedhandheldprintprojectionscreenttytvmedia="braille" sourceElement source is a REQUIRED choice between itself, <plain-text>, and <markup> from <session>. The intent of this tag is to allow an external resource to act as the message body. There is no requirement for a MML processor to process any external resource, so the content established by this element SHALL NOT always be communicated.<source>↔</source> source-uri source-type source-uriElement source-uri is a REQUIRED child of <source>. This tag MUST only contain a URI of the requested resource that is to act as the body of the session.<source-uri>http://mailmarkup.org/FlyingToGhazni.mp4</source-uri> source-typeElement source-type is a REQUIRED child of <source>. This tag is of element type "mime-type". The type determines how or if the external resource described in <source-uri> MUST be processed by the document's destination.<source-type><video>mpeg4-generic</video></source-type> plain-textElement plain-text is a REQUIRED choice between itself, <source>, and <markup> from <session>. This tag MUST contain only plain text. Code MUST NOT be processed in this tag. The intent of this tag is to allow session authors to communicate using text without interference to the processing of that content. Presentation MAY be applied to this element's content if the MML processor so allows and a stylesheet is provided.<plain-text>This is a plain text message body.</plain-text> markupElement markup is a REQUIRED choice between itself, <source>, and <plain-text> of <session>. The elements in this section of MML are arranged in three groups: complex-blocks, simple-blocks, and inline elements. A complex-block is a tag that is capable of containing of either simple-blocks or simple-blocks plus other complex-blocks. Complex-blocks are not capable of containing text content or inline elements. A simple-block is a tag that is capable of containing text and inline elements, but is not capable of containing other simple-blocks or complex-blocks. Inline elements are not structural elements. These elements MUST exist in a simple-block container. Inline elements are intended to describe text content, supply additional meta-data, or apply more specific presentation.<markup>↔</markup> complex-blocks simple-blocks Any elements provided they exist with a namespace prefix in accordance with a stated namespace definition. Namespace prefixed elements, aside from those that fall into the "xfm" namespace, MUST NOT be validated by the MML schema. Any attribute with a namespace prefix of "xmlns". Value of an attribute prefixed with "xmlns" should be URI. (optional and may occur more than once) core-attrsAttribute group core-attrs contains the attributes that are globally available to markup elements aside from a few rare exceptions. id (optional) style (optional) title (optional) role (optional) core-attrs-uriAttribute group core-attrs-uri is identical to the core-attrs attribute group with the exception to inclusion of the uri attribute. It was necessary to specify these two groups separately because many elements require a URI and many MUST NOT receive a URI. id (optional) style (optional) title (optional) role (optional) uri (optional) inter-attrsAttribute group inter-attrs exists to benefit features of internationalization of text rendering. This is not a presentation issue of altering how text appears, but how it functionally contributes to processing dependencies to the computer for the benefit of assistive technologies. MML processors SHOULD allow users to determine the default rendering methods of text. tl (optional) orientation (optional) wrap (optional) section-language (optional) cell-attrsAttribute group cell-attrs stores attributes relevent to table cell merging. span-column (optional) span-row (optional) idAttribute id is an optional global attribute of the core-attrs and core-attrs-uri attribute groups. This attribute exists to assign a unique identification to an element. The value for this attribute MUST NOT contain punctuation, white space, or XML syntax characters. The value MUST allow Unicode word characters in accordance with the XML regular expression definition for a word character. This attribute is intended to create a unique hook to a particular element for MML processor specific behavior or presentation. There are some elements that exist as a pair set and require the id attribute to refer to each other. The id attribute MUST be unique per <session> section and SHALL NOT be unique per a MML document of multiple sessions.id="Science_Article_20100101" styleAttribute style is an optional global attribute of the core-attrs and core-attrs-uri attribute groups. This attribute exists to reference a reusable stylesheet property. The value for this attribute MUST be a set of Unicode word characters in accordance with the XML regular expression definition of a word character plus a colon followed by a series of Unicode word characters. The value before the colon MUST represent the value of any supplied stylesheet-namespace attribute. This tells the MML processor which stylesheet the style reference is referring to. The value after the colon MUST represent some designation defined in the stylesheet, such as a CSS class name.style="global:comparisonGridTitle" titleAttribute title is an optional global attribute of the core-attrs and core-attrs-uri attribute groups. The title attribute is intended to supply additional content to an element beyond its contained text. The value for this attribute MUST be whitespace normalized text. This attribute is supplied for the semantic and accessibility benefits of expanded meta-data for human consumption.title="This attribute could be used to supply additional instructions or data outside the context of the element's content." roleAttribute role is an optional global attribute of the core-attrs and core-attrs-uri attribute groups. This attribute is intended to allow for specific semantic redefinition of any element where its use is allowed. If a session author had the ability to rename a tag to something more semantically specific that new name is the value that SHOULD fill the role attribute. The value of the role attribute SHOULD NOT challenge or contradict the intent of the named element it is used with.This attribute is expected to offer significantly expanded utility in future versions of MML. The WAI-ARIA technology and RDF derived technologies are expected to benefit from use of the role attribute.role="instructions" uriAttribute uri is an optional global attribute of the core-attrs-uri attribute group. This attribute MUST contain only a URI value as defined by RFC 3986 or RFC 2368 for email addresses specifically. Use of this attribute is equivalent to imposing a webpage hyperlink. A same-document referrence, referred to as a URI fragment, MUST refer only to the value of a specified id attribute value within the same session. A minimum value length of 5 characters is REQUIRED.uri="http://mailmarkup.org/examplePage.html#fragment" directionThe direction attribute is an optional global attribute of the inter-attrs attribute group. The direction Attribute determines which direction the text is to flow as it is typed. The default value is left to right if orientation has a value of horizontal or top to bottom if orientation has a value of vertical.direction="br" tl - indicates starting from top or leftbr - indicates starting from bottom or right orientationAttribute orientation is an optional global attribute of the inter-attrs attribute group. This attribute determines whether text characters render in a vertical or horizontal manner. Horizontal is the default value. Acceptable values are: horizontalverticalorientation="horizontal" wrapAttribute wrap is an optional global attribute of the inter-attrs attribute group. This attribute determines how lines of text are rendered to the page. A value of "standard" does nothing different and is the default value. The value "reverse" MUST force text render opposite of its standard behavior.Assuming direction and orientation are at default standard behavior is to wrap a line of text below the prior existing text. Under those conditions a value of "reverse" MUST force the line of text to wrap above the prior existing line of text.A value of "none" forces the text to not wrap. Under the condition that non-wrapping text is wider or taller than its container the container MUST stretch and the page MUST scroll to keep the text visibly legible so long as there are not presentation specifications to the contrary. standardreversenonewrap="reverse" section-languageAttribute section-language is an optional global attribute of the inter-attrs attribute group. The attribute section-language specifies the language of a particular section, container, or element in the <markup> section. This is absolutely necessary to alert readers and semantic devices that the natural language has changed from the default specified language. The values for this attribute MUST be ISO 639 language code.section-language="haz" referAttribute refer is a required attribute of <cite> and <identifier> elements and is an optional attribute of <button>. This attribute is a reference to the value of an id attribute supplied on another element of the same <markup> section. If the value of this attribute does not match an existent id attribute value of only the same session the document MUST NOT validate.refer="inventory21793-28" span-columnAttribute span-column is an optional attribute of cell-attrs attribute group. This attribute allows a <table-cell> or <head-cell> to occupy more than one column in a table. The values for this attribute MUST be a positive integer. The default value is "1".span-column="3" span-rowAttribute span-row isan optional attribute of cell-attrs attribute group. The attribute span-row allows a <table-cell> or <head-cell> to occupy more than one row in a table. The values for this attribute MUST be a positive integer. The default value is "1".span-row="4" scopeAttribute scope is an optional attribute of the <head-cell> element. This attribute is used in table header cells to determine which table cells the header is providing a heading for. The value "column" dictates that a header cell is providing a heading for only the first column of cells the header cell occupies. The value "row" dictates that a header cell is providing a heading for only the first row of cells the header cell occupies. A value of "group-column" dictates that a header cell provides a heading for all cells in all columns that it occupies. The value "group-row" dictates the header cell is providing a heading for all cells in all rows it occupies.The word first, as used in defining column and row as values to the scope attribute, MUST refer to the first group of elements as dictated by the rendering direction of text set using internationalization attributes. columnrowgroup-columngroup-rowscope="group-column" long-formAttribute long-form is a required attribute of <short>. This attribute MUST serve to represent the expanded text that is described by the <short> element.long-form="Afghan National Army" complex-blocksA complex block is a tag that is capable of containing simple blocks or complex blocks, but is not capable of containing text. A choice of one of the contained elements is REQUIRED at each instantiation of this group. list-group table section form simple-blocksA simple block is a tag that is capable of containing text and/or line-level tags, but is not capable of containing complex blocks. A choice of one of the contained elements is REQUIRED at each instantiation of this group. block-code block-quote citation heading object paragraph separator simple-blocks-typeComplex type simple-blocks-type is a generic simple block element representation. inline (optional) core-attrs inter-attrs inlineElement group inline is a collection of inline elements. A choice of one of the contained elements is REQUIRED at each instantiation of this group. xfm:Form.Controls short button cite emphasis identifier quote format strong title object-groupElement group object-group contains the elements necessary to represent a binary large object (BLOB) data asset. inline (optional) object-text (required) object-uri (required) object-type (required) inline-baseComplex type inline-base is a generic inline element representation referenced from inline-type complex-type. core-attrs-uri inline-typeComplex type inline-type is a container of the inline-base complex type plus a constaining facet that requires at least 1 character be contained by generic inline elements. format-typeComplex type format-type represents the structure of the <format> element necessary to allow that element to nest itself. format (optional) core-attrs-uri list-groupElement group list-group contains the various list type elements. A choice of one of the contained elements is REQUIRED at each instantiation of this group. define-list navigation-list order-list unorder-list nesting-blockComplex type nesting-block is the unique structure supplied for the <section> element which is the complex block capable of nesting itself. complex-blocks simple-blocks define-listElement define-list is a member of group list-group and is a complex block element. This element is intended to establish a list of definitions by matching any number of defining terms to any number of definitions.<define-list>↔</define-list> define-item (required and may occur more than once) core-attrs define-itemElement define-item is a required child of element <define-list>. This element represents a single defining instance. The associations drawn by the child tags are as follows: multiple defining terms mapped to a single definition, a single term mapped against multiple definitions, or multiple terms that commonly share multiple definitions. As a result of these three possible associations at least one of each child element MUST occur.<define-item>↔</define-item> define-term (required and may occur more than once) definition (required and may occur more than once) core-attrs define-termElement define-term is a required child of element <define-item>. This tag is intended to contain a single term, phrase, or clause to be defined. The value for this tag MUST be whitespace normalized text.<define-term>Hazara</define-term> core-attrs-uri inter-attrs definitionElement definition is a required child of element <define-item>. This tag is intended to contain the definition text that defines the associated terms. The value for this tag can be text and inline elements.<definition>a commonly discriminated major ethinic minority of central Afghanistan</definition> inline (optional) core-attrs inter-attrs navigation-listElement navigation-list is a member of group list-group and is a complex block element. This element establishes a list of items that exist to either direct traffic or create a menu of URIs. This tag allows for either a heading or a set of descriptive text and at least one navigation item.<navigation-list>↔</navigation-list> heading (optional choice of heading or identifier) identifier (optional choice of heading or identifier) navigation-item (required and may occur more than once) core-attrs navigation-itemElement navigation-item is a required child of element <navigation-list>. This element is a single instance of navigation in a list of navigation choices. This element may contain either an object for navigation or text for navigation as determined by its child tags. A uri attribute is REQUIRED on this element.<navigation-item>↔</navigation-item> navigation-object (required choice of navigation-object or navigation-text) navigation-text (required choice of navigation-object or navigation-text) core-attrs uri (required) navigation-objectElement navigation-object is a required choice between itself and element <navigation-text> of element <navigation-item>. This element is a standard <object> that is modified to not allow use of the uri attribute. This tag SHOULD only be used if the focus of navigation for the <navigation-item> of concern is an external resource expected to be processed into the content of the message body.<navigation-object>↔</navigation-object> object-text (required) object-uri (required) object-type (required) inter-attrs core-attrs object-textElement object-text is a required child of <navigation-object> and <object>. Object text is the alternative text content that is to be rendered as content if the object cannot be resolved or processed.<object-text>alternative text that represents or describes a binary large object (BLOB) data asset</object-text> object-uriElement object-uri is a required child of <navigation-object> and <object>. This element MUST only contain a URI value and that URI MUST point to the location of a resource to appear in the message body.<object-uri>http://mailmarkup.org/mail.pdf</object-uri> object-typeElement object-type is a required child of <navigation-object> and <object>. This element is of complex type "mime-type".<object-type><application>pdf</application></object-type> navigation-textElement navigation-text is a required choice between itself and element <navigation-object> of element <navigation-item>. This element contains text and whitespace that is the focus of a navigation item.<navigation-text>This is text that would be a navigation item in a list of navigation items.</navigation-text> inter-attrs core-attrs order-listElement order-list is a member of group list-group and is a complex block element. An ordered list is a list where each item in that list is enumerated in the meta-data so that the position of elements in the list relative to other list items is valid data. Whether or not this enumeration appears is to a human reader is strictly a presentation concern. This element is allowed descriptive text in the form of a <heading> or <identifier> child. Each item in the list MUST exist in the <list-item> child.<order-list>↔</order-list> heading (optional choice between heading and identifier) identifier (optional choice between heading and identifier) list-item (required and may occur more than once) core-attrs unorder-listElement order-list is a member of group list-group and is a complex block element. An unordered list is nearly identical to an ordered list except that list items are not enumerated. This means position of items in the list is irrelevant.<unorder-list>↔</unorder-list> heading (optional choice between heading and identifier) identifier (optional choice between heading and identifier) list-item (required and may occur more than once) core-attrs list-itemElement list-item is a required child of <order-list> and <order-list>. This element represents a single listed instantiation in a either an ordered or unordered list. This element may contain a single simple block element or text plus 0 or more inline elements.<list-item><paragraph>a paragraph in a list-item</paragraph></list-item> simple-blocks (required choice of a simple block or text and inline elements) inline (required choice of a simple block or text and inline elements) core-attrs inter-attrs formElement form is a member of group complex-blocks. This element is the high level parent container of a form. A form allows organized controls upon input and submission of information in various methods allowed by the XForms standard.<form>↔<form> xfm:model (required) form-body (required) form-bodyElement form-body is a required child of <form>. This element is intended to contain all the form controls that a user could interact with plus other MML elements. A choice of elements from one of the three included element groups or the <table> element is required and that choice may occur more than once.<form-body>↔<form-body> list-group simple-blocks xfm:UI.Common table tableElement table is a member of element group complex-blocks and is an optional child of <form-body>. This element allows authors to store and organize data in a grid or chart fashion.<table>↔</table> head-row (optional) table-row (required and may occur more than once) core-attrs head-rowElement head-row is an optional child of <table>. The header row is a container of header cells to provide meta-data for tables. <head-row>↔</head-row> head-cell (required and may occur more than once) core-attrs head-cellElement head-cell is a required child of <head-row> and an optional child of <table-row>. A header cell provides meta-data that either labels or describes the data contained within its scope. The scope of the header cell is determined by use of the scope attribute. A header cell MUST contain either a single simple block or text plus any number of inline elements.<head-cell><paragraph>Example of a paragraph in a table's head cell.</paragraph></head-cell> simple-blocks inline scope cell-attrs core-attrs inter-attrs table-rowElement table-row is a required child of <table>. This element MAY carry header cells or standard table cells. A row is the standard unit of organization in a MML table.<table-row>↔</table-row> head-cell (required choice between head-cell and table-cell that may occur more than once) table-cell (required choice between head-cell and table-cell that may occur more than once) core-attrs table-cellElement table-cell is a required child of <table-row>. The table cell is the standard unit of data in a table. A table cell is not intended to provide any meta-data about the table or the structure of the table. A table cell is intended to provide data directly to the user. A table cell MUST contain either a single complex block or text plus any number of inline elements.<table-cell>some data here</table-cell> simple-blocks inline cell-attrs core-attrs inter-attrs sectionElement section is a member of element group complex-blocks. A section is a high level structural organization block. This is the only complex block capable of containing itself, such as nesting. The intent of the <section> tag is to subdivide the markup into various smaller areas for content organization, separation, and semantics.<section><heading>heading</heading><section>↔</section></section> core-attrs block-codeElement block-code is a member of element group simple-blocks and is formed of the complex type simple-blocks-type. The block code simple block is intended to convey and describe code. The contents of this container MUST NOT directly contain XML reserved characters. An XML processor cannot be told to not process characters that construct its syntax. These reserved characters can be used if they are escaped with a character entity reference. Unlike the <plain-text> tag it is the author's responsibility to ensure the contents of this element are properly encoded. Improperly encoded reserved characters SHOULD expect a result of failure at validation. The reserved characters and their corresponding character entity references are: < - &#60; - &lt;> - &#62; - &gt;& - &#38; - &amp;" - &#34; - &quot;' - &#39; - &apos;<block-code>var JavaScriptFunction = function () {var test = "hello Bagram"; return test;};</block-code> block-quoteElement block-quote is a member of element group simple-blocks and is formed of the complex type simple-blocks-type. A block quote is a large quotation that MAY span several statements. This element can contain text and any number of inline elements.<block-quote>This is a lengthy paraphrase that is better represented apart from other paragraphs.</block-quote> citationElement citation is a member of element group simple-blocks. A citation is a descriptive reference to a piece of information used in content by a session author. The information referenced by the <citation> tag automatically points to the content that requires it by use of a REQUIRED id attribute, which is referred to by the inline tag <cite>. This element contains text and any number of inline elements.<citation id="SAFE">Cheney A. "Server-side Asynchronus Framework Execution", Internet Draft, Sabre Holdings, Aug 2009.</citation> inline id (required) style (optional) title (optional) role (optional) inter-attrs headingElement block-code is a member of element group simple-blocks and is formed of the complex type simple-blocks-type. A heading is a short block of text that describes the content that is to follow. This element MUST contain text and MAY contain 0 or more inline elements.<heading>This is a heading.<heading> objectElement citation is a member of element group simple-blocks. An object is any external resource that is intended to be processed among the content of the message body, such as an image or video. It is important that an object contain text content that describes its resource. It is OPTIONAL for MML processors to process any external resource. If the resource fails to process according to the value of <object-type> the text contained by the object MUST display.<object>↔</object> object-group inter-attrs core-attrs paragraphElement paragraph is a member of element group simple-blocks and is formed of the complex type simple-blocks-type. This element is the standard generic container of text and inline elements in a MML document. This element represents a paragraph and text is most typically grouped in paragraphs.<paragraph>This is a text paragraph.</paragraph> separatorElement separator is a member of element group simple-blocks and is formed of the complex type simple-blocks-type. This element is intended for semantic and structural purposes only. Use of this element indicates a structural obstruction in the flow or organization of content within a single section. This element MAY contain text, which would indicate or explain the nature or reasoning of separation mandated by use of this element.<separator>This page intentionally left blank.</separator> short-typeComplex type short-type is for representing inline element <short>. long-form (required) core-attrs-uri shortElement short is a member of element group inline and is formed from complex type short-type. This inline element describes text that is a short-hand value, such as an abbreviation or acronym.<short id="ANA">Afghan National Army<short> button-typeComplex type button-type is for representing element <button>. refer (optional) core-attrs-uri buttonElement button is a member of element group inline and is formed from complex type button-type. This element exists to encourage interaction from a user outside of a form. This version of MML does not allow for client-side scripting, limiting the potential of a button, although a button MAY be able to interact with media that performs its own internal scripting, such as Flash media.<button refer="intro_paragraph">This button uses the refer attribute, which MAY function as a URI fragment identifier in the absense of the uri attribute.</button> cite-typeComplex type cite-type is for representing element <cite>. refer core-attrs citeElement cite is a member of element group inline and is formed from complex type cite-type. This element is intended to contain text begging a citation. The refer attribute is REQUIRED as it MUST point to the id attribute of a <citation> in the same <markup> section of the document. The refer attribute on this element MAY act as a fragment URI to send users to the location of the targeted <citation> element in the session.<cite refer="SAFE">Footnote 1<cite> emphasisElement emphasis is a member of element group inline and is formed from complex type inline-type. This tag indicates the text it contains is more important than other text of the same context.<emphasis>This is emphasized text.</emphasis> identifier-typeComplex type identifier-type is for representing element <identifier>. refer core-attrs-uri identifierElement identifier is a member of element group inline and is formed from complex type identifier-type. This element is intended to provide a text label that describes some other element. This element has a REQUIRED attribute of refer so that it may refer to the id of the element it is attempting to describe.<identifier refer="elementID">A reference to an specific point in the <markup>.</identifier> quoteElement quote is a member of element group inline and is formed from complex type inline-type. This element indicates the content it contains is a quotation.<quote>Why minify assets and not the markup?</quote> formatElement format is a member of element group inline and is formed from complex type format-type. The format tag is a special tag. This is the only tag in the entire MML tag set that is deliberately intended to provide no semantic data. This tag is available to provide access to the core attributes without imposing semantic considerations. A session author MAY need to apply style or a uri attribute to some text that is otherwise no different than the text around it. This is also the only inline tag that MAY contain a child tag.<format style="cars:subscript">Normal text with a different <format role="notation">presentation</format>.</format> strongElement strong is a member of element group inline and is formed from complex type inline-type. This tag indicates the content it contains is begging attention regardless of the importantce or relevance of the content in its given context.<strong>Ouch!</strong> titleElement title is a member of element group inline and is formed from complex type inline-type. This element indicates either a person's official title or the title of a work.<title>Mail Markup Language</title> Bos B, Celik T, Hickson I, Lie H. "Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification", W3C Candidate Recommendation, W3C, Stanford, Opera, July 2007. http://www.w3.org/TR/CSS21/ Crocker D. "Standard for the Format of ARPA Internet Text Messages", University of Delaware, August 1982. http://www.ietf.org/rfc/rfc822.txtResnick P. "Internet Message Format", RFC 2822, Qualcomm, April 2001. http://www.ietf.org/rfc/rfc2822.txt Hickson I. "HTML 5", WHATWG Draft Recommendation, WHATWG, August 2008. http://whatwg.org/html5/ Fielding R, Gettys J, Mogul J, Frystyk H, Masinter L, Leach P, Berners-Lee T. "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, UC Irvine, Compaq, W3C, MIT, Xerox, Microsoft, June 1999. http://www.ietf.org/rfc/rfc2616.txt Reynolds J, Postel J. "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciecnes Institut , October 1994. http://www.ietf.org/rfc/rfc1700.txt Crispin M. "Internet Message Access Protocol, Version 4rev1", RFC 3501, University of Washington, March 2003. http://www.ietf.org/rfc/rfc3501.txt Gabel T, Sure Y, Voelker J. "Kaon -- An Overview: Karlsruhe Ontology Management Infrastructure", University of Karlsruhe, April 2004. http://kaon.semanticweb.org/main_kaonOverview.pdf Bradner S. "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. http://www.ietf.org/rfc/rfc2119.txt Freed N, Borenstein N. "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual, November 1996. http://www.ietf.org/rfc/rfc2045.txtFreed N, Borenstein N. "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft, First Virtual, November 1996. http://www.ietf.org/rfc/rfc2045.txtMoore K. "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, University of Tennessee, November 1996. http://www.ietf.org/rfc/rfc2047.txtNelson S, Parks C, Mitra. "The Model Primary Content Type for Multipurpose Internet Mail Extensions", RFC 2077, LLNL, NIST, WorldMaker, January 1997. http://www.ietf.org/rfc/rfc2077.txtFreed N, Klensin J. "Media Type Specifications and Registration Procedures", RFC 4288, Sun Microsystems, December 2005. http://www.ietf.org/rfc/rfc4288.txtFreed N, Klensin J. "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 4289, Sun Microsystems, December 2005. http://www.ietf.org/rfc/rfc4289.txt Bray T, Hollander D, Layman A, Tobin R. "Namespaces in XML 1.0 (Second Edition)", W3C Recommendation, Textuality, Contivo Inc, Microsoft, Univerity of Edinburgh and Markup Technology Ltd, August 2006. http://www.w3.org/TR/REC-xml-names/ McGuinness D, Harmelen F. "OWL Web Ontology Language Overview", W3C Recommendation, Stanford University, Vrije Universiteit, February 2004. http://www.w3.org/TR/owl-features/ Myers J, Rose M. "Post Office Protocol - Version 3", RFC 1939, Carnegie Mellon, Dover Beach Consulting Inc, May 2006. http://www.ietf.org/rfc/rfc1939.txt Klyne G, Carroll J, McBride B. "Resource Description Framework (RDF): Concepts and Abstract Syntax", W3C Recommendation, Nine by Nine, Hewlett Packard Labs, February 2004. http://www.w3.org/TR/rdf-concepts/ Cheney A. "SAFE (Server-side Asynchronous Framework Execution) Scripting Method", Sabre Inc., 5 Aug 2009. Klensin J. "Simple Mail Transfer Protocol", RFC 2821, AT&T Laboratories, April 2001. http://www.ietf.org/rfc/rfc2821.txt Mead G, "Mind, Self & Society From the Stand-Point of A Social Behaviorist", University of Chicago Press, 1947. [BOOK] Berners-Lee T, Fielding R, Masinter L. "Universal Resource Identifiers (URI): Generic Syntax", RFC 3986, W3C/MIT, Day Software, Adobe Systems, January 2005. http://www.ietf.org/rfc/rfc3986.txtHoffman P, Masinter L, Zawinski J. "The mailto URL Scheme", RFC 2368, Internet Mail Consortium, Xerox Corporation, Netscape Communications, July 1998. http://www.ietf.org/rfc/rfc2368.txtMealling M, Denenberg R. "RFC3305 - Report from the Joint W3C/IETF URI Planning Interest", RFC 3305, W3C URI Interest Group, August 2002. http://www.ietf.org/rfc/rfc3305.txt Connolly D, Masinter L. "The 'text/html' Media Type", RFC 2854, W3C, AT&T, June 2000. http://www.ietf.org/rfc/rfc2854.txt Fallside D, Walmsley P. "XML Schema Part 0: Primer Second Edition", W3C Recommendation, IBM, October 2004. http://www.w3.org/TR/xmlschema-0/Walmsley P. "Definitive XML Schema", Prentice Hall, December 2001. [BOOK] Cooper M, Schwerdtfeger R, Seeman L, Pappas L. "Accessible Rich Internet Applications (WAI-ARIA) Version 1.0", W3C Working Draft, W3C, IBM, UB Access, Society for Technical Communication, August 2008. http://www.w3.org/TR/wai-aria/ Caldwell B, Cooper M, Guarino R, Vanderheiden G. "Web Content Accessibility Guidelines 2.0", W3C Candidate Recommendation, University of Wisconsin-Madison, W3C, Google Inc., Trace R&D Center, April 2008. http://www.w3.org/TR/WCAG20/ Boyer J. "XForms 1.0 (Third Edition)", W3C Recommendation, IBM, October 2007. http://www.w3.org/TR/2007/REC-xforms-20071029/ Bray T, Paoli J, Sperberg-McQueen C, Maler E, Yergeau, F. "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C Recommendation, Textuality, Microsoft, W3C, Sun, August 2006. http://www.w3.org/TR/REC-xml/REC-xml-20060816.xml Berglund A. "Extensible Stylesheet Language (XSL) Version 1.1", W3C Recommendation, IBM, December 2006. http://www.w3.org/TR/xsl/ Pemberton S, Austin D, Axelsson J, Celik T, Dominiak D, Elenbaas H, Epperson B, Ishikawa M, Matsui S, McCarron S, Navarro A, Peruvemba S, Relyea R, Schnitzenbaumer S, Start P. "XHTML 1.0 The Extensible HyperText Markup Language (Second Edition)", W3C Recommendation, CWI, W3C, Grainger, Opera Software, Microsoft, Openwave Systems, Philips Electronics, Netscape/AOL, Panasonic, Applied Testing and Technology, WebGeek Inc., Oracle, SAP, Sony Ericsson, August 2002. http://www.w3.org/TR/xhtml1/ Axelsson J, Birbeck M, Dubinko M, Epperson B, Ishikawa M, McCarron S, Navarro A, Pemberton S. "XHTML 2.0", W3C Working Draft, Opera Software, x-port.net, Websense, W3C, Applied Testing and Technology, WebGeek Inc., CWI, July 2006. http://www.w3.org/TR/xhtml2/ I would like to thank all those wonder people who supported me, without which this would not have been possible. Some of those people are Dustin Askins, Don Hay, Craig Hoersten, David McCarty, Stephen Marshall, the technology and legal executives of Sabre, and my wife Melissa. Mail Markup Language, MML, is a method of structuring, defining, and describing content and data in email for a variety of reasons. Please refer to http://mailmarkup.org for more information. First implementation begun by Austin Cheney on 12 October 2007.