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:[email protected]] > Sent: Tuesday, March 24, 2009 10:42 AM > To: Robert Miner > Cc: Paul Libbrecht; Math Working Group; [email protected]; Professor > James Davenport; [email protected] > 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 _______________________________________________ Om3 mailing list [email protected] http://openmath.org/mailman/listinfo/om3
