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

[Robert Miner]

Hi.

James wrote:

> As for the first, am I right in the following:
> (a) This wouldn't preclude OM developing intcond etc. later;
> (b) Since Strict will be isomorphic to OM, these will therefore be
part
> of strict;
> (c) Therefore pragmatic->strict COULD be (pace David, I won't say
> WOULD) be enhanced to use these in the future?
> If I am right here, then we probably have a way forward that works
> today and doesn't preclude growth tomorrow.

You are more expert than I am, but this is what I was thinking/hoping
was correct.  And your conclusion is exactly what I am looking for -- a
way forward that works today and doesn't preclude growth tomorrow.

Of course, as you point out, something still needs to be done about
uplimit/lowlimit vs interval for integrals.  Your proposal for a
solution to that will be welcome.

--Robert


> -----Original Message-----
> From: Professor James Davenport [mailto:jhd at cs.bath.ac.uk]
> Sent: Tuesday, March 24, 2009 10:42 AM
> To: Robert Miner
> Cc: Paul Libbrecht; Math Working Group; om3 at openmath.org; Professor
> James Davenport; c.a.rowley at open.ac.uk
> Subject: RE: [Om3] Being pragmatic about the semantics of, eg,
> variables and functions
> 
> On Tue, March 24, 2009 3:01 pm, Robert Miner wrote:
> > I'm not sure we are talking about the same proposals.  You mention
> adding
> > a condition child to OMBIND, and while that has been mentioned by
> several
> > people, I don't think there is a concrete proposal spelling out the
> I think the (full) D/K paper is such a proposal, but it's only a
> proposal,
> and many are against it.
> > details of that.  From the MathML point of view, I think that would
> amount
> > to allowing <condition> in strict markup.  To me, that pushes off
the
> Not quite. To me, it allows <condition> in strict markup WHERE the CDs
> permit such a binding operator. Now, this pushes work off to the CDs,
> and
> if MathML is such that that means <condition> is allowed anywhere in
> strict markup since CD verification is optional (I just don't know) I
> can
> understand more objections to that.
> > problem to the future, and allows OM to specify the mapping to OM3
> later.
> >
> > I'm okay with that, since it decouples the OM3 work from the MML3
> work.
> See below.
> 
> > It isn't the OM -> XXX direction that is hard.  It is the pragmatic
-
> >
> > strict mapping that is hard.
> I understand that,
> 
> > I think you are talking about OM here.  From my MathML viewpoint,
> there
> > isn't a problem with readability or writability: use pragmatic
> markup.
> > The problem is algorithmically mapping it to strict markup, for
which
> I
> > don't think readability or writability is very important --
pragmatic
> > markup is already the solution to that problem.
> ? unless roundtripping via strict/OM makes the readable unreadable.
> >
> > To summarize, my main interest at this point is decoupling the work
> on
> > MathML 3 from the resolution of this OM3 debate.  I really think we
> have
> > to finish Chapter 4 in a matter of weeks -- completely -- and I just
> can't
> > see how to do that, as long as filling out the strict markup for the
> > remaining operators and examples in 4.4 depends on the conclusion of
> the
> > OM3 binder debate.  Thus, the argument I'm making is that the only
> > feasible thing to do for MathML 3 is to carry on using the current
> text
> > (which essentially makes strict CMML isomorphic to OM2).  That
allows
> me
> > to reuse more exposition from MML2, it allows us to stick with the
> > examples and strict equivalents David already produced, and so on.
> I understand the need to get finished, and there are moments when the
> perfect is the enemy of the good. as I see it, this would leave:
> (*) "Rule 2" --- "Note that the order of bound variables..." (4.2.3.2
> of
> MML2) in place as the means of tying up the x in the integrand with
the
> x
> (or whatever) in the domain;
> (*) An issue with uplimit/lowlimit versus intervals in int.
> If I'm right on the second, I'll come back with a proposal on it.
> 
> As for the first, am I right in the following:
> (a) This wouldn't preclude OM developing intcond etc. later;
> (b) Since Strict will be isomorphic to OM, these will therefore be
part
> of
> strict;
> (c) Therefore pragmatic->strict COULD be (pace David, I won't say
> WOULD)
> be enhanced to use these in the future?
> If I am right here, then we probably have a way forward that works
> today
> and doesn't preclude growth tomorrow.
> 
> James Davenport
> Visiting Full Professor, University of Waterloo
> Otherwise:
> Hebron & Medlock Professor of Information Technology and
> Chairman, Powerful Computing WP, University of Bath
> OpenMath Content Dictionary Editor and Programme Chair, OpenMath 2009
> IMU Committee on Electronic Information and Communication