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
