[Om3] Being pragmatic about the semantics of, eg, variables and functions

[David Carlisle]

> 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. 
________________________________________________________________________