> That's not quite the same thing (fortunately). If Chapter 4 is merely A > translation Prag->S (which is what I would hope) then evolving OM will let > us improve a "best efforts" translation, which would be a nice position to > be in.
it's not just _a_ translation. In MathML 1 and 2 the meaning of the content markup was given in a CD-like appendix using a notation and prose style that was unique to mathml. Under that model, there is scope for any number of "best effort" conversions from MML to OM. In MathML3 the meaning of the content markup is defined by its translation to strict. So (unless there is an error in the spec, which happens of course) an alternative, later, translation to strict mathml must produce something that is mathematically equivalent, as the element is defined by the specified translation. > Which essentially means, as I understand it, that 'condition' is either IN > or OUT, irrespective of CDs. yes but of course it doesn't have to mean anything. You can construct all kinds of expressions that don't have any obvious semantic <apply><cn>1</cn><condition><pi/></condition><cn>2</cn></apply> is valid mathml which perhaps means the function 1 applied to 2, restricted to the subset determined by pi thought of as a predicate You can form this expression and probably even render it and convert it to OpenMath, but as far as I can guess it is meaningless (and if you come up with a meaning for this I could come up with a sillier example:-) The Schema will allow the condition element on head terms where condition has no obvious meaning and it will allow expressions as content of condition that have no obvious interpretation as a predicate. That's just (XML) life. > Agreed, but there were certainly a few uses of 'condition' in MML2 that I > couldn't assign any sensible meaning to. Yes but hopefully there will be fewer in mathml3. One problem with the build process of the mathml2 spec was that it had a lot of examples spread over chapter 4 and the appendix c, and we had no way really of checking them (other than that they were dtd-valid). One of the benefits of the new scheme is that we should be able to mechanically check the sanity of far more of the examples by mechanically (or semi-mechanically) coverting all examples to strict mathml. Currently that process fails in some cases, but the process of checking the failures is stalled pending this discussion as it's hard to tell if a bad translation is due to an error in the conversion or an error in the original example, while the details of what's legal mathml and what the conversion to strict should be are in flux. There are pros and cons of allowing condition in strict mathml, if you do, you can punt on giving meaning to some of the stranger uses, as you just leave them in strict mathml and they mean whatever they mean. This makes the mathml spec look simpler, but perhaps doesn't really help the user or implementer who still has to figure out what to do with the expression. If on the other hand we don't allow condition in strict (which is the status quo) then the rewrite to strict has to be explit in the spec which forces us to decide what that rewrite should be which means we get to argue now and whatever the result of this discussion some expressions will be somewhat "strained" while rewriting. As Robert commented, from a MathML perspective, the fact that some expressions get slightly awkward rewrites isn't really a problem, it's just giving the formal underpinnings of the mathml constructs. Users who don't want to use the fully expanded strict form can use the original mathml markup, that's what it's there for. If there are common constructs that don't have a simple encoding in OM that is perhaps more of a problem for OM, however as seen in the replies last night to Florian, I think the existing markup is in many cases simpler than people think, and certainly a lot simpler than expressions using exotic binding constructs. David ________________________________________________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. ________________________________________________________________________ _______________________________________________ Om3 mailing list [email protected] http://openmath.org/mailman/listinfo/om3
