Combing markup

I’m new to MathML, and want to check my understanding of the specification.  I’ve been researching MathML in preparation to use it to allow our math editing software to communicate with other applications.  It seems that there are various ways that content and presentation markup can be included in the same document, and applications are free to produce and read combined markup in a way that makes the most sense for the purpose of the application.  Each method of combining markup is useful for different reasons, and application developers should decide which methods are most useful for their application.  I have gone through several methods of combining markup and indicated, to the best of my knowledge, where and why each method might be used.  I’m hoping that someone will read and respond to my notes, and provide feedback, indicating where I am wrong or missing important points concerning the purpose of the combination method.

 

* Mixed Markup, as described in section 5.2 of the specification, is useful when an application is primarily either for presentation or computation.  One would choose one type of markup as the “primary” markup, and embed the other type of markup as “hints”.  So if an application renders MathML that is meant primarily for viewing, the application would use mostly presentation markup, and include content markup to provide any meaning that is not immediately obvious, or the default semantic for the presentation.  For example, “f(x)” can be thought as “F times quantity x,” instead of “F of x,” which is a more common usage of the notation.  Including the content markup in the presentation markup clarifies the meaning.  (Computation-oriented applications will want to include presentation markup when a particular expression should be presented a certain way.  For example, should 1/x be written as a fraction, or x to the power of –1?)

 

* Top-level parallel markup, section 5.3.1, has two parallel branches. One is presentation markup, and the other is content markup.  This allows an application to present the expression in the desired form, as well as communicate the semantics of the expression.  The limitation of top-level parallel markup is that the correspondence between the content and presentation markup is only for the entire expression.  If an application wants to manipulate (copy, edit, etc.) sub expressions, top-level parallel markup does not indicate how a sub expression in one branch corresponds to the other branch.  Each sub expression can have a presentation branch and a content branch, but this can cause the MathML document to become very large.

 

* Parallel markup via id and xref allows for the MathML document to have one branch for each type of markup, and still allows the application to deal with sub expressions.  Both the content markup and the presentation markup are present, and an application can match a sub expression in one branch to its counterpart in the other branch.

 

* From section 7.2.1: “developers are given wide latitude in interpreting what kind of MathML implementation is meaningful for their own particular application.”  This means that applications can choose how to respond to various ways MathML is authored.  For example, a content-oriented application interpret presentation markup that is embedded in content markup, as well as display the expression correct when a document uses top-level parallel markup, but the application does not manipulate sub expressions when id and xref attributes are present.  Also, the same application can produce a MathML document that uses only content MathML.

 

* If the primary goal is to communicate with other applications that support MathML, one needs to consider which types of applications one wishes to communicate with, so the MathML rendered is the one that’s best suited for that type. Parallel Markup will probably be the most flexible choice, because it allows an application to parse either the content markup or the presentation markup, or use both simultaneously.  But it’s not necessarily always the best choice (it might be overkill for one’s purposes.)

 

I look forward to any feedback you have.  Thank you for your time.

 

Sincerely,

Carole Snyder

Henter Math