Allow intent attribute on content mathml #289
Comments
|
Unless you're asking to expose Content MathML trees to AT, so that they can be read for accessibility in a way different than the underlying tree suggests, It is certainly not meant as an OpenMath replacement at the moment. And unless you are going for a replacement, I wouldn't introduce yet another mechanism as a parallel option - we've had objections to that in the meeting (by Moritz, and I'll join him). A big reason we got where we did with the intent work is having the group consensus to keep the Content chapter "frozen", or at least functionally frozen, while we get the accessibility considerations sorted out. Side-note: I'm a bit confused by All of this said, my opinion is that we should keep |
|
@dginev name is allowed on csymbol so you can do The empty case looks like a typo in mathml3 spec there is a reference
with an unfortunately empty csymbol, although it is describing the usage in the immediately following mathml fragment where the content is As for allowing
relates to
Maybe it's OK to say the first is sin x with sin function as described in OpenMath transc1 CD and the second is sin x with sin as described in (wherever we say intent is described) and leave it to the reader to decide if they are at all the same thing, |
|
@davidcarlisle interesting about It is difficult to word this in the way I want it to sound, but here is a try: The mixed nature of the Presentation tree (which is polluted/enhanced with content bits) and the Content tree (which is polluted/enhanced with presentation bits) may be worth reopening at the next iteration of spec work (5th MathML) and cleaned up to a nearly unrecognizable state. The mixed responsibility/capability between the chapters makes it look as if we have two competing specs at times. So we should either integrate them into one cohesive tree, or really disentangle into two (or more) trees. At least that's a direction of my current thinking. Which is also why I'd rather keep the Content chapter frozen until such an opportune time comes up. Putting my pragmatic hat back on, I had offered to Moritz that we can view the intent lists in our spreadsheets as a custom "content dictionary" for now, until we have something better to do with them. So, in your example: <mi intent="sin" id="ex1">sin</mi>can be seen as <csymbol cd="intent" xref="ex1">sin</csymbol>where I added the cross-references for spice. Instead of adding a new attribute to Content MathML, we might as well try to use it as intended and add a new |
|
@dginev yes actually having a "virtual" CD which maps to whatever intent is mapping to would I think answer the mapping question we (at OpenMath) have had similar dynamic Cds before eg cds that meant "whatever function I just defined in gap" (or maple, as the case may be) . I suspect this issue somehow won't go away but I'm not pushing too hard to actually change too much at this stage. Not least our current charter https://www.w3.org/Math/Documents/Charter2021.html says
Which probably means we shouldn't be undercutting the foundational basis for Content MathML in this iteration:-) |
|
I should have been more explicit in my "suggestion". I was viewing If that is the case, that the accessibility information is different from the content information, then it is conceivable that someone would want to add accessibility information to content as well as presentation. Clearly that's a much less important usecase. But what could be the harm in allowing it, I thought? Little did I know :> I definitely did not intend the suggestion as in any way replacing or superseding anything in Content MathML. We may eventually want to develop a lighter-weight alternative to OpenMath CDs; and it may even end up desirable to use the same "dictionary" mechanisms (but likely not the same dictionaries) that we settle on for intent. But unless we're able to design intent from the start to handle both, I don't think we should be even hinting at double duty. |
|
@brucemiller ah I see, but even though intent is being positioned mostly for accessibility I can't see how we could allow it on content without it effectively ending up as an alternative to the CD reference mechanism. I would guess though his issue ends up being a collecting ground for ideas that come up and storing them for possible consideration in mathml.next. |
|
I worry that if |
|
OK let's park this, close or invent a "defer for consideration at a future version" label? |
|
I agree, whatever potential benefit isn't worth the almost guaranteed confusion. |
|
At the call on 2022-03-24 it was clear that there were still discussions around intent on Content, so I'm re-opening this so that any new discussion doesn't get separated from earlier comments Support for intent in Content MathML could be imagined at several levels.
The issue was opened floating an idea around level 1, and it was agreed that for timing and charter reasons if nothing else, such a radical refactoring of Content MathML was out of scope, but re-opening to allow other options to be considered. One issue with level 2 is that (presumably) intent on presentation will be defined to affect the accessibility tree, but (currently at least?) Content MathML is dropped from the A.T. Level 3 may seem quite weak for a specification but possibly puts the accessibility hints on Content in the same status as the general visual presentation, being explicitly system specific, with just sample non-normative renderings given, Level 4 is a coherent option and there was some support for it on the last call especially along the grounds that we should not experiment in the specification, just specify what has been proved to be interoperable. But I worry that making it invalid is preventing experimentation anywhere. |
I don't understand this worry, because it doesn't reflect any development lifecycle I am currently aware of. Experimentation has been/is possible by using Experimentation is also possible with a validator, if one forks and modifies the official schema and allows the attribute - then validating against this modified schema. I would imagine XML-capable vendors are well-accustomed to such uses in private. And they can re-serialize as What is the role of the MathML specification here? To give room to experiments, or to standardize "best practice", production use in accessibility? I would like it to be the latter, because the former is already possible using different avenues. If we lack confidence that we currently can standardize a good method for improving accessibility, in my mind it would be better to defer the Intent component to MathML 5, rather than to offer a solution that leads to confusing and non-standard uses. In my personal opinion, such choices will hurt adoption (noticeably) more than it will benefit experimentation. It would also be in better sync with the charter to avoid adding new attributes to Content MathML. It sends a clearer message for us to keep Content MathML substantively frozen, until a more overarching revision becomes possible. It is possible, inevitable even, that I am quite ignorant to expectations for using MathML by stakeholders that are not openly represented in the current working group. I would love to learn more specifics about those workflows, so that we can have an opportunity to make an informed decision. |
Some specifications may just be standardising best practice but not I think specifications of languages. If you look at a specification of XPath or XSLT (or MathML 1) then it is defining the language from scratch and there is no practice (best or otherwise) prior to the publication of the spec. As MathML4 is a 4th iteration there is some component of standardising best practice MathML use as observed from previous iterations but that is not the only focus. It is still the specification of a new iteration of the language and we are chartered to add something equivalent to the intent attribute for which there is no existing practice at all, so best practice is not an issue. There are pros and cons to adding intent to content elements but lack of existing use to determine best practice is not an issue as that applies to any new feature, including adding intent to presentation. Currently I am leaning towards "level 3" in #289 (comment) : That is allow intent on content but not mandate any behaviour, just suggest it may be used in content-to-presentation transforms. I think it certainly could be used to good effect to control transformations from content to presentation+intent which otherwise will always end up using a default intent (or equivalently no intent at all) |
|
I strongly agree with David's last comment: Intents do not have an existing best-practice at all. Allowing intent on content-MathML without specifying a behaviour is a reasonable agreement which will allow room to explore and create practice and then best-practices. I vaguely imagine that content-MathML with intent may bring audio-guided interactive navigation of expressions at a more synthetic level than what can be done on presentation-MathML, for example. That's just a 2 minutes idea. I also do not think that adding intents to content-MathML is significantly changing MathML-content. |
|
David and Paul, Please consider that when I wrote my original comment I was aware that we are introducing a new attribute without existing practice. And that my sentences:
were pointed to the future, implying that the WG will standardize (= create + recommend) a novel use of the intent attribute. I believe you don't need me to point to the reasons for the creation of "MathML Core", to demonstrate the issues you encounter with undefined behavior. I also provided my current technical understanding as to why the "experimentation" argument is not a convincing one, to my reading. I was genuine in my request for further information in that vein. I appreciate many have strong preferences here, but we'll have to resolve our disagreements by entering this question in detail rather than in passing. Maybe this is the type of discussion we can productively spend a weekly meeting slot on. Did XSLT allow attributes on nodes "but not mandate any behaviour, just suggest it may be used in [certain] transforms"? This is also interesting and an example would help me here as well, so as to appreciate this aspect of evolving specifications. I had a much longer statement prepared, but I think it will be better received in a meeting. |
|
@dginev I think you are reading too much in to undefined behaviour here. The intent attribute is part of presentation, (mainly aimed at non visual presentations, but still) and Content MathML by design has a presentation form that is system-specific and not mandated, so if intent is added to it, then more or less necessarily it will have a system-specific behaviour. This is not just a failure to specify on the part of the WG to be corrected later. Chapter 4 gives some possible renderings of Content MathML to Presentation MathML, and once we have specified intent, these sample presentations can use intent for better accessibility (#284). Showing some sample presentations using intent that take a source being content mathml using intent would be in the same spirit. |
That would imply that the WG is in a position to introduce best practice. That is, I feel, a far far utopic goal. We do have expertise to carry the perspective, the language spec and early implementations but for the enabled practice to become best, we can only wait for the world to receive, taste, and evaluate.
No you don't. The worlds are totally different. As far as MathML-content goes, the low-spread of its attested use makes it also a very modest target and, as OpenMath has been, a more common carrier of research than of widespread use. Studying best practice there (or in intents) requires more practice and more research. |
|
@dginev you argued in the call that declaring This really isn' t the case, the situation is very similar to aria attributes for which you took the opposite approach and demonstrated them on Content MathML. Aria was never valid MathML 3, the draft MathML4 schema allows them in MathML Core, which inherit into Presentation MathML, but don't currently make them valid on Content MathML. We could decide to make aria attributes also valid on Content MathML (and probably should). If you use aria attributes on Content MathML in a browser whether they have an effect will depend on the polyfill being used to process the MathML. (my c2p xsl stylesheet and related javascript version would discard them, I'm not sure aria existed when that was originally written). The MathML spec can not constrain that polyfill, all it can do is declare whether or not an aria-label attribute is valid MathML. This is consistent with the general nature of the full spec which (unlike core) is primarily a specification of the format, not of behaviour. The same is true of intent. If you use intent on presentation elements not in core their effect in a browser will depend on the polyfill in use, if mfenced is replaced by mrow+mo for the delimiters, the polyfill may or may not construct an intent for the mrow using an intent specified on the mfenced. How that polyfill works is not specified here, what we can specify is whether the document is valid if it has intent on mfenced. The same is true on an mrow with intent that is re-written to an mtable construct by a linebreaking polyfill. The proposal for intent would be simply be to add it to the global attributes (rather than the common presentation attributes as now) so it is valid. We could say nothing at all about its effect on content mathml, or we could say in the spec explicitly that it is valid and may be used as input to any transformations to presentation mathml, so affecting accessibility and audio renderings of that presentation. So the suggested change is one line of schema and a most a couple of sentences in the spec. This is not a "major change" and it is essentially just about internal spec consistency. What we say here (just as your demonstration of aria shows) depends on things that are out of scope for the mathml spec. But some things are in scope and in our control, we can ensure that any examples of aria or intent that we want to demonstrate are valid MathML 4. |
|
It seems like a good idea to allow an attribute on Content MathML which
suggests how the expression should be rendered, but I think it is a
mistake to overload "intent" for that purpose.
The discussions about "intent" have centered on the idea of disambiguating
Presentation MathML. We have focused on pronunciation, but most people
think of it as conveying the meaning. You can't know how to pronounce
|x|
unless you know it is absolute value, or determinant, or ....
My point is that the point of "intent" in Presentation MathML has no
place in a context where the meaning is already unambiguous. Using
"intent" for a completely different purpose just asks for confusion
or abuse.
The claim that it is easy to just change one line in the schema,
applies equally well to another attribute which more clearly serves
the purpose of guiding the appearance of Content MathML.
|
|
I have already offered my full perspective in the comments here and in yesterday's meeting. For context: the last comment by @davidcarlisle addressed my gist with experimental markup for binomials, which aimed to illustrate:
In my eyes, specifying and recommending AT behavior over Content MathML is a major change to Content MathML. The charter makes the sequence of events clear, emphasis mine:
For me to hold this view, I consider the attribute being allowed on the tree a very minor step towards addressing the use case of accessible narration over Content trees. So minor as to be misleading, without having done the rest of the prototyping work involved. That said, adding a separate attribute to Content with the singular purpose of being copied into an |
|
As @davidfarmer says, if the content mathml is unambiguous, the pronunciation can probably be deduced without You might say it should be a csymbol pointing at a to-be-produced Airy function OpenMath CD, or you might say it should have a might help (alhough I think Ai(z) gets pronounced as A-eye of z as often as not, but ignoring that for now)
So I can experiment with Really I see no downsides to this, and I don't accept that this is a major change with charter implications. You didn't answer my implied question about the schema allowing Aria. I didn't consider that a major change either, So I did not raise as a separate issue at time it just got done as part of a first sketch draft of schemas for mathml4 and no one objected. I would have added |
I would have thought it is implied as covered in my sentence:
I don't think we should spend any time working on this topic during this iteration, and already feel that we've spent too much time on whether to address it. There is explicit language in the charter to avoid this entire discussion. If I suspected it would be interpreted so freely, I would have spoken up back when the "Out of Scope" text got written. |
|
I don't see that the charter is being interpreted "freely". We are not talking about any change in required behaviour of implementations, just discussing whether usage that may already be used is marked as valid or invalid. Validity is of course an important part of the specification but it makes no difference to most people and most applications. Witness the percentage of valid html pages on the web. The charter isn't relevant to the discussion at all, it lays the broad framework for the working group, not intended to micro-manage the language design down to individual attributes. My sense of thursday's call was that you were the only one to speak against this, alhough of course most WG members haven't said either way so we'll see what the Group consensus is. Actually I have some more general issues about which attributes should or should not be global (specifically attributes that are global in core such as |
|
On 5/13/22 13:43, David Carlisle wrote:
As @davidfarmer <https://github.com/davidfarmer> says, if the content
mathml is unambiguous, the pronunciation can probably be deduced without
|intent|, so it's probably most useful to help with less then perfect
content MathML
At some point in long past discussions, *someone* convinced me that even
if we had both presentation and content, it wouldn't yield appropriate
speech. The implication was that intent should not be *purely* about
disambiguation, nor in any way "equivalent" to content.
This seems to me a rather fundamental distinction and unless
we are aligned (whichever point of view), we will
inevitably work at cross purposes.
Alas, I cannot remember who, or the specific examples.
Perhaps i simply misunderstood or misremembered?
If I seem to be the only one raising this point,
and myself only mildly convinced of it,
perhaps I should just give it up.
|<apply><ci>Ai</ci><ci>z</ci></apply> |
You might say it should be a csymbol pointing at a to-be-produced Airy
function OpenMath CD, or you might say it should have a |definitionURL|
Indeed, I would! :>
But that is a clear case of disambiguation where content
could/should have clarified.
More interesting perhaps are legitimate variables that still need
speech hints of some kind; eg
```
<ci intent="mass">m</ci>
```
or in presentation
```
<mi intent="mass">m</mi>
```
That would seem useful if one takes the intent-is-not-content POV.
From the other POV, one might argue that the example should be using
aria, rather than intent.
|
|
One more try for me to reach @davidcarlisle ...
Exactly, which is where
Again, this is consistent with
Yes. You would need a
The paragraph above is stating exactly what it stated - this is your added-value interpretation of it. I disagree.
The downsides are both technical and strategic and I see them clearly.
The initial closing of this issue had 4 voices that understood the underlying threats of departing on this route. What has transpired since is really unfortunate. Luckily you still have my voice trying to alert the group to what it's about to do. It's a strategic mistake. Please avoid it. |
I was referring to "either this specification should be extended to provide the feature explicitly" which is an explicit option suggesting that the relevant specification (mathml here) be extended. Not any "value-added" addition that I had added.
Given that Content MathML systems should provide a presentation but that presentation is system specific and not defined, it is hard to imagine how you envisage specifying the behaviour of intent (or any other attribute) more specifically than that.
Actually (although we do need to fix this) we don't have a clearcut definition at all yet. We don't have a grammar for intent and I think that intent on non core presentation elements have almost exactly the same issues as intent on content mathml elements, as to a browser they are the same thing: unknown elements in the mathml namespace that only have any rendering if they are converted to core mathml via javascript. So we have to decide if |
Yes, this is where we are at. "intent on Content" is also the only discussion that is in the scope of the specific github issue ( #289 ). Discussions about intent on Presentation MathML Full, finalized grammar, etc. should be taken elsewhere. As you suggest - the design isn't finalized in any of the directions of work. [redacted] |
Ah good, Because I really thought I wasn't understanding your comments at all, so glad I got that far.
Yes sure, discussions for those things should be elsewhere but we can't decide each part of the specification in isolation, so happy to park this issue and come back to it later when things are clearer. If for example we decide that
I certainly hope that you continue to contribute, Working Group consensus can't always mean unanimous agreement, but I don't think it makes sense to ask for consensus on this issue until the specification of intent generally is more than just a couple of sketched paragraphs. It may be that when things are clearer, the consensus will be to agree with you and not to make this valid on Content. If so, so be it. https://davidcarlisle.github.io/mathml/intent.html In a MathML-Core enabled browser that renders as three (x,y) each with an intent of pair(x,y) which will have an effect so long as That file will work in that way whatever we decide here, nothing affects the browser behaviour, the only question is whether the input is useful enough to be considered valid, or if it should be considered invalid. |
|
Hey @dginev, I think that making this discussion a hard case is what we disagree on: For me (and I think a few others) it is far less work to accept not prohibiting intent on content instead of resolving the question weather it can bring best or worst practice. Does it help interpret our attitudes? |
|
Thank you @polx . I appreciate and accept that bridge perspective. Let cooler heads prevail and park here then. I hope I can find a common path forward together with everyone. I have cleaned up some of my previous comments in an attempt to undo undeserved provocation. |
|
I can still see no rationale for not allowing intent on all of MathML. Making it valid on presentation but not content assumes I think there are two separate languages involved, but that has never been the case, it is one combined language with elements that can be mixed freely. For example would be invalid, which would mean we could not describe the default intent on mfrac (or any element) as
as there would be valid children of mfrac that do not take
Allowing intent on all MathML elements makes the language more consistent and easier to document and avoids producers having to add spurious extra verbose markup to work around an arbitrary restriction. of course the particular example above could be addressed by allowing |
|
Please update the charter language before you vote on this. You may have a classic perspective where there is one language involved, but the charter clearly has my perspective written into the out-of-scope text: (will avoid repeating my comment in full) quote:
The additions are clearly scoped to the Presentation branch. Mixtures of Presentation and Content would appear to be covered insofar as the Content is used as-is from MathML 3. The group may have reached consensus to not follow the chartered bounds, so please revise the charter text. @davidcarlisle You are facing an "an arbitrary restriction", I am facing a "gratuitous extension". An extension that goes against the charter scope as I understand it and is offered with no prototyping work behind it. I am also skeptical that advertising this use of mixed presentation+content MathML is well-positioned moving forward. Maybe my line of thinking is leaning in a direction for a "Content MathML Core" variant that is yet to be discussed, prototyped and evaluated. One I had hoped we could examine in the fifth iteration of the Math WG work rather than now. It could inch closer to enhanced support in browsers, while keeping full compatibility with MathML Core. But, considering the history of MathML Core itself, I can see how there are other paths to approach such a task. |
|
@dginev As discussed above, the charter has absolutely no bearing on this issue. If you want to discuss technical proposals, then fine but really I have said all that can be said about the charter here. Adding a global attribute to MathML can in no way be considered a significant change to content mathml, it wouldn't need any changes chapter four or the mathml-content schema, just chapter 2 and the common schema, which are the natural places for global attributes. But in any case legal wordsmithing around the charter is a bizarre way to attempt to shut down technical discussion. |
|
To summarize my current feelings:
I think we should explore what I see two ways content can be used with
Dispensing with some easier(?) content element/
With the exception of I'm not sure what should happen with From this point on, the discussion is "thinking out loud" and is just raising discussion points because I'm not sure what is right. Thoughts/questions:
|
|
@NSoiffer wrote
Yes I agree with this and as I mentiond on last week's call the current draft is somewhat silent on how but those ways apply equally to mfenced or mstack, the browser really doesn't distinguish elments that are not in core So skipping to your final questions
I think this is the easiest to answer and it should be allowed and not ignored. in (The XML sources for the nag library have 5,154 instances of
as for mfenced, if it is passed to AT it will inform the voice rendering of that subterm, if instead the expression is passed through a transform to MathML Core then that transform should generate suitable intent values on the generated elments but exactly which Core elements it generates and what attributes they have is out of scope for the spec. But again this exactly the same as elementary math elements. |
|
@NSoiffer as for presentation mathml we only need to consider individual elments if we want to specify default intent values, something we have not addressed so far. chapter 5 doesn't need to say how intent acts on each element, but if we want content elements are the same. The existing description covers all elements (controls the voice rendering for the subterm) we only need to consider individual elements if we want to define defaults so |
|
@davidcarlisle wrote:
There maybe is a difference... If I could write the transforms properly, they would make use of the Shadow DOM and so AT wouldn't see the results of the transform, whether for @davidcarlisle also wrote:
That made me think about the potential problem case: If the |
To an implementation there is no "Presentation MathML" other than Core, so you could not make such a distinction. Note unknown elements don't have undefined behaviour they lay out like mrow and global attributes mostly have their defined behaviour. in the
Where As a global attribute I would expect to be able to use
Sure but that is already true with |
For a specification, (1) seems to me the only valid point of view, as we cannot specify the use of intent on content in terms of some unknown transformation. If you are writing a content to presentation transform and want to preserve intent, you'll need to transform the content's intent values as well. With luck, it may only be necessary to copy the
I've been viewing |
If you think of this as an annotated MathML tree, then speaking it is no problem (other than what the AT will do with
Exactly! (from my POV). If you want to transform to presentation, you'll need to migrate the |
We should not specify the transformation but we have to specify whether the input is valid or not. The question of whether it is allowed is separate from saying what happens if you use it. (As in MathMlL Core where we are saying intent is valid but not saying a system has to pass it to AT or do anything at all with it) So I think we should make it valid. To also have (1) , that is, it gets passed to AT, I think we'd have to specify that intent works that way for all unknown elements in the MathML namespace, as content elements are not in Core, so are Unknown. (as I commented above with |
|
If we're talking about Core, then you're right: none of this matters; whether |
|
@brucemiller |
|
@davidcarlisle , right, I think I understand what you're saying, but not necessarily the implication. I'm beginning to suspect that we're actually debating different questions. I was thinking about how intent on Content elements should be structured, such as the guidance we would provide to a document author about how to formulate such intent attributes. For me, the only approach that makes sense is case (1) where the intent is written as if the content elements were being processed by the AT. Without knowing the c2p transformation, I don't see how case (2) specifies anything at all about what I should put into the intent value. Maybe that was obvious to everyone else, all along, but some comments had me wondering. Of course, how the intent actually finds its way into the AT is another question to resolve. |
|
With the above discussion, I reluctantly agree that case '2' (while the more likely method AT will see That leaves the question of whether |
|
@davidcarlisle wrote about rabbit elements (a clever way to say we are going down a rabbit hole with this discussion?) Because any element in the MathML namespace that is not in core is treated as an unknown element, including those that are defined in MathML Full, that's a strong reason why we need to say something about all elements in the MathML namespace need to get into an accessibility tree. Throwing out the elementary math elements would destroy elementary school accessibility. This part of the discussion probably belongs in a different issue though. |
|
I actually don't think (for the spec) there is any difference betwen (1) and (2) it is just an implementation detail. For MathML3 implementation report each specific browser+javascript+xslt was considered "an implementation" and it is same here. I'd note first that this issue (289) is not about how intent affects anything simply whether it shoud be allowed. But this issue is asking for less: it is just asking that intent is not declared invalid, so that you are allowed to have javascript that uses it in any way. |
|
Neil wrote
acrually I think it is the fundamental part of this issue, if we want unknown elements including their intent attributes to be passed to AT then we are saying we want to specify that intent works on Content MathML. |
|
Generally, I like the symmetry of allowing Alternatively, for the case where the Content is transformed (somehow) into Presentation before AT sees it, I would think that the transformer would already have most information that it needs to annotate the presentation with intent. Are there compelling cases where a better result would be obtained by carrying intent from the Content over to the Presentation? |
Basically any example where intent is being used to customise the audio rendering rather than give mathematical meaning. But really the logic for the suggested change in his issue is much simpler, You will be able to use intent on content mathml and a browser will do what it does, applying a javascript transform or passing it or not passing it to AT depending on what ends up being the specified behaviour for unknown elements. So really the more natural question is, What is the compelling use case for declaring implemented behaviour as invalid? The whole discussion has zero impact on implementations, it only concerns validity and most implementaions don't check |
Something as simply as |
|
So, part of the rationale is that for intent to be usable on out-of-core elements like |
|
On the call on 2022-08-11 the working group resolved with no objections to make the change suggested by this issue. It was noted that Deyan may have spoken against had he been there but we went through the comments here and there was a clear consenus to apply this change for the FPWD. |
SHA: 6c3a019 Reason: push, by @davidcarlisle Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
In a PR comment
#286 (comment)
@brucemiller asks if
intent=should be allowed in content,I'm tempted to say it should, basically be allowed everywhere
cdis allowed (including in the grammar for strict content)In MathML2 we had inline in the spec an "openmath-light" appendix giving some kind of semantic meaning to each content element. The "Content Element Definitions" appendix: https://www.w3.org/TR/MathML2/appendixc.html
Maintaining that was a lot of work and being in the published rec meant it wasn't extensible once published.
So in MathML3 we "outsourced" this to OpenMath which was under active (funded) development at the time and provided a general framework for recording these sorts of definitions. So in MathML3 the meaning of Content MathML was expressed by rewriting to the simplified strict grammar and then linking each csymbol with an OpenMath symbol.
For
intentwe will need something similar: we have the basic intent grammar which ultimately requires giving meaning to the terminal literals, currently these are by reference to the spreadsheethttps://docs.google.com/spreadsheets/d/1EsWou1K5nxBdLPvQapdoA9h-s8lg_qjn8fJH64g9izQ/edit?usp=sharing
But we have a plan to set up some more structured view of these.
We could use OpenMath again to ground intent terms, but I suspect we will want a lighter weight system that is easier to update (or we could use wikipdia or whatever)
Once that system is in place I don't see any reason not to allow it on
csymbol.Taking the canonical superscript-meaning-power example:
If
<msup intent="power"references whatever dictionary we have to say this means power, then it would make sense for<apply><csymbol intent="power">power</csymbol>to reference the same thing rather than (as now) Strict content mathml requiring<apply><csymbol cd="arith1" name="power">power</csymbol>with some additional specificaion somewhere that relates the intent attribute dictionary to the core openmath cd group that covers content mathml.So... I'd propose we allow
intentwherever we allowcdto allow the use of this alternative mechanism to ground the meaning of content mathml.We could take the further step of changing the rewrite rules to use
intentrather thancdso<apply><sin/>rewrites to<apply><csymbol intent="sin">sin</csymbol>raher than<apply><csymbol cd="transc1" name="sin">sin</csymbol>which would bring things back in-house and remove the normative dependency on OpenMath, but we don't have to decide to do that before deciding whether to allowintent.The text was updated successfully, but these errors were encountered: