MathML-Next and HTTP POST

[AdamSobieski]

Introduction

How can resources referenced by <annotation> and <annotation-xml> elements be retrieved utilizing HTTP POST? How can we provide the annotation data of mathematical expressions as input to such resources and services?

In the discussion below, MathML4 syntactic options are presented with which to provide mathematical expressions’ annotation data, e.g. semantic content, as data when utilizing HTTP POST to access indicated resources and services.

Comments and discussion are welcomed.

Encapsulating Third-party Services with PHP Scripts

Let us consider a third-party service at https://www.thirdparty.com/needs-mmlc-data-in-post.php. The service requires a mathematical expression’s semantic content as input and it returns some or all of the mathematical expressions’ derivations in some XML-based format to be determined.

Before exploring <annotation> and <annotation-xml> elements which can access such resources utilizing HTTP POST, the scenario’s solution space includes encapsulating the third-party service. A server-side PHP script, e.g. “derivation.php”, could load a mathematical expression’s semantic content and utilize it to access the third-party service to then return the service’s output to end-users.

<math id="eq1">
  <semantics>
    <annotation-xml encoding="application/mathml-presentation+xml" src="eq1.mmlp" />
    <annotation-xml name="contentequiv" encoding="application/mathml-content+xml" src="eq1.mmlc" />
    <annotation-xml definitionURL="http://www.example.com/" cd="cd" name="derivation" encoding="application/tbd+xml" src="derivation.php?equation=eq1" />
  </semantics>
</math>

Posting Mathematical Expressions to Resources and Services

Let us again consider a third-party service at https://www.thirdparty.com/needs-mmlc-data-in-post.php. The service requires a mathematical expression’s semantic content as input and it returns some or all of the mathematical expressions’ derivations in some XML-based format to be determined.

In the approach to be considered, end-users are desired to access the third-party service themselves should they desire to explore some or all of the derivations of a mathematical expression.

<math id="eq1">
  <semantics>
    <annotation-xml encoding="application/mathml-presentation+xml" src="eq1.mmlp" />
    <annotation-xml name="contentequiv" encoding="application/mathml-content+xml" src="eq1.mmlc" />
    <annotation-xml definitionURL="http://www.example.com/" cd="cd" name="derivation" encoding="application/tbd+xml" src="https://www.thirdparty.com/needs-mmlc-data-in-post.php" />
  </semantics>
</math>

Firstly, we would like to be able to indicate that the resource or service is to be accessed via HTTP POST. This could be achieved via a method attribute (see also: HTML5 <form> element).

<math id="eq1">
  <semantics>
    <annotation-xml encoding="application/mathml-presentation+xml" src="eq1.mmlp" />
    <annotation-xml name="contentequiv" encoding="application/mathml-content+xml" src="eq1.mmlc" />
    <annotation-xml method="post" definitionURL="http://www.example.com/" cd="cd" name="derivation" encoding="application/tbd+xml" src="https://www.thirdparty.com/needs-mmlc-data-in-post.php" />
  </semantics>
</math>

Next, we would like to be able to indicate the encoding type for the POST. This could be achieved via an enctype attribute (see also: HTML5 <form> element).

<math id="eq1">
  <semantics>
    <annotation-xml encoding="application/mathml-presentation+xml" src="eq1.mmlp" />
    <annotation-xml name="contentequiv" encoding="application/mathml-content+xml" src="eq1.mmlc" />
    <annotation-xml method="post" enctype="multipart/form-data" definitionURL="http://www.example.com/" cd="cd" name="derivation" encoding="application/tbd+xml" src="https://www.thirdparty.com/needs-mmlc-data-in-post.php" />
  </semantics>
</math>

Next, we would like to be able to indicate the character encoding for the POST. This could be achieved via an accept-charset attribute (see also: HTML5 <form> element).

<math id="eq1">
  <semantics>
    <annotation-xml encoding="application/mathml-presentation+xml" src="eq1.mmlp" />
    <annotation-xml name="contentequiv" encoding="application/mathml-content+xml" src="eq1.mmlc" />
    <annotation-xml method="post" enctype="multipart/form-data" accept-charset="utf-8" definitionURL="http://www.example.com/" cd="cd" name="derivation" encoding="application/tbd+xml" src="https://www.thirdparty.com/needs-mmlc-data-in-post.php" />
  </semantics>
</math>

Next, we would like to be able to refer to a semantic annotation by id to refer to the annotation’s data. We can add an id attribute to the expression’s semantic annotation.

<math id="eq1">
  <semantics>
    <annotation-xml encoding="application/mathml-presentation+xml" src="eq1.mmlp" />
    <annotation-xml id="eq1-semantics" name="contentequiv" encoding="application/mathml-content+xml" src="eq1.mmlc" />
    <annotation-xml method="post" enctype="multipart/form-data" accept-charset="utf-8" definitionURL="http://www.example.com/" cd="cd" name="derivation" encoding="application/tbd+xml" src="https://www.thirdparty.com/needs-mmlc-data-in-post.php" />
  </semantics>
</math>

Finally, we would like to be able to indicate that a POST parameter has the value of the expression’s semantics. An HTTP POST parameter, “content”, is desired to have as its value the data referred to by the semantic annotation with the id of “eq1-semantics”. That is, to access the service at https://www.thirdparty.com/needs-mmlc-data-in-post.php, a browser must first download the resource of type application/mathml-content+xml from the relative URL “eq1.mmlc” to pass to the service as a POST parameter named “content”.

There are a number of possible syntactic approaches.

Approach 1: A data Attribute

data="content={get-annotation-data-by-id('eq1-semantics')}"

<math id="eq1">
  <semantics>
    <annotation-xml encoding="application/mathml-presentation+xml" src="eq1.mmlp" />
    <annotation-xml id="eq1-semantics" name="contentequiv" encoding="application/mathml-content+xml" src="eq1.mmlc" />
    <annotation-xml method="post" enctype="multipart/form-data" accept-charset="utf-8" data="content={get-annotation-data-by-id('eq1-semantics')}" definitionURL="http://www.example.com/" cd="cd" name="derivation" encoding="application/tbd+xml" src="https://www.thirdparty.com/needs-mmlc-data-in-post.php" />
  </semantics>
</math>

Advantages of a data attribute approach – utilizing a string interpolation syntax resembling that of a possible pattern attribute (see: https://github.com/mathml-refresh/mathml/issues/68) – include that values could be specified for multiple POST parameters.

Obtaining Presentation from Content and Content from Presentation

The following example showcases the expressiveness with which to articulate that presentation content can be obtained from semantic content.

<math id="eq1">
  <semantics>
    <annotation-xml encoding="application/mathml-presentation+xml" method="post" enctype="multipart/form-data" accept-charset="utf-8" src="math-c2p.php" data="content={get-annotation-data-by-id('eq1-semantics')}&amp;language={lang}&amp;notation={notation}" />
    <annotation-xml id="eq1-semantics" encoding="application/mathml-content+xml" src="eq1.mmlc" />
  </semantics>
</math>

The following example showcases the expressiveness with which to articulate that semantic content can be obtained from presentation content.

<math id="eq1">
  <semantics>
    <annotation-xml id="eq1-presentation" encoding="application/mathml-presentation+xml" src="eq1.mmlp" />
    <annotation-xml encoding="application/mathml-content+xml" method="post" enctype="multipart/form-data" accept-charset="utf-8" src="math-p2c.php" data="presentation={get-annotation-data-by-id('eq1-presentation')}" />
  </semantics>
</math>

Conclusion

In the discussion above, MathML4 syntactic options were presented with which to access resources via HTTP POST. Syntactic options were also presented with which to provide the annotation data of mathematical expressions, e.g. semantic content, to such resources and services.

[davidcarlisle]

A client side javascript can already use data from annotations from a semantics element as specified in the mathml-core draft and initiate ajax get or post connections to a server to update the display.

Adding a new native POST capability to MathML core would open up a host of additional security and interaction issues and make implementing mathml core that much harder (if it is not completely vetoed by the browser implementers). I don't think this should be considered for the spec unless there is clear advance agreement that it would be implemented in browsers in mathml-core.

[AdamSobieski]

A point is that browsers already include secure HTTP POST functionality for HTML5 forms and much or all of that existing functionality could be reused for MathML4 – were it to include HTTP POST for annotations.

Such functionality, which could also be implemented in JavaScript, would be useful for passing mathematical expressions as input to resources and services. While shorter mathematical expressions could be passed as URL query string parameter values, for larger or arbitrarily large mathematical expressions, HTTP POST features would be useful.

[NSoiffer]

I agree with @davidcarlisle: this likely brings up lots of security questions. The fact that is used on another element doesn't mean the browser makers are willing to add it somewhere else. The href attr that MathML 3 allows on all elements is apparently problem and not supported in core due to security issues. Hence, there is already a counterexample to the "it is allowed elsewhere so it isn't a problem to add it somewhere new" argument.

If you can convince browser implementers to allow it, then it can be considered. Without their buy-in, this won't happen.

Also, this really is a MathML Core feature, so most appropriately should be moved there.

[AdamSobieski]

Thank you. The envisioned deliverable is a “Proof Web”, “Argument Web”, or “Inference Web” where end-users could click on, or utilize context-menus on, formulas, expressions, and claims to open tabs for Web documents containing proofs, arguments, or justifications such that contents thereof could similarly, recursively, have proofs, arguments, or justifications available for users to explore.

Use cases include, but are not limited to: logic, mathematics, critical thinking, argumentation, philosophy, and law digital textbooks where these resources could enable learners to explore reasoning supporting and opposing specific contents of interest to them.

There are to consider, in these regards, both second- and third-party service-provider scenarios. A third-party service provider which would convenience second-parties desiring to provide these user experiences might resemble ProofWiki.

To the implementation-related ideas presented, above, it appears that POST would be better than GET for reasons including: (1) individual formulas, expressions, or claims could be POSTed to service providers using one or more representation formats, (2) relevant contextual data could also be POSTed to service providers. Some context data might be needed to accompany individual formulas, expressions, or claims and, in theory, Web browser software should be able to process next-generation document markup to produce any needed contextual data with which to precisely obtain remote resources described by the documents and desired by the end-users.

Brainstorming, it might also be that data models like the Web Annotation Data Model and related Web protocols like the Web Annotation Protocol could be useful for these scenarios.

To your points, the matter might, then, be one of describing and perhaps producing simulated demos and videos of “Proof Web”, “Argument Web”, or “Inference Web" functionalities and related user experiences (perhaps considering logic, mathematics, critical thinking, argumentation, philosophy, and law education) to browser implementer teams and communities so as to catalyze or renew interest in these described deliverables. In the event of sufficient interest, it would then be a matter of working to deliver the best specifications and implementations.

[dginev]

[minor admin] In the MathML Full WG meeting on Sep 28th, 2023, we agreed to re-title issues scheduled for the next charter with "MathML-Next", to avoid confusion.