Hi. I think I end up with basically the same plan of action as Michael. Here is how I think through it:
The plan we've been working on is that pragmatic markup continues more or less as it always has, but that the spec would define its semantics by providing a normative mapping to a "strict subset" instead of an idiosyncratic (and wrong and inconsistent, etc) appendix. The strict subset alone isn't sufficient, since it doesn't itself define the semantics of its symbols. So we were going to ground it by pointing to OM CDs for those definitions. At the time we made that decision, the idea was to point to OM3, not OM2, where OM3 would be free to change in response to what was needed to better push through the above program, and would be done before MML3. Obviously, this hasn't happened, and I think people are generally acknowledging that the timing constraints are such that is can't happen anymore. Consequently, there isn't really any room for debate on the basic point that MML3 is stuck referencing OM2. Now, it was also a goal that strict markup be structurally isomorphic to OM3. Note, however, this is not a requirement for pushing through the above program. It doesn't even have to be structurally isomorphic to OM2, so long as it is logically sound. The problem we are facing is that it can a) be isomorphic to OM2, b) try to be isomorphic to OM3, c) be loosely defined so it can be isomorphic to either. Given the lively debate over OM3, I don't think b is likely to succeed on the compulsory timeline that confronts us, even if we all agree it is what we want (which we don't). That leaves a or c. Where Michael ended up in his email (my interpretation) is that we have to proceed on the basis of a), and if the OM3 debate progresses fast enough try our best to switch to c) at the last minute if there is time. We probably differ on the details of what "switching to c at the last minute means" -- with Michael hoping to actually have time to change some of the details of the P2ST transform, and my thinking we will be lucky if we can manage to open up the schema enough to at least allow strict markup to be isomorphic to OM3. But that can await events, and once the timing and content of OM3 is clearer, that question should answer itself. --Robert > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Professor James Davenport > Sent: Wednesday, March 25, 2009 7:00 AM > To: David Carlisle > Cc: [email protected]; [email protected]; [email protected] > Subject: Re: [Om3] Being pragmatic about the semantics of, eg, > variables and functions > > > On Tue, March 24, 2009 10:04 pm, David Carlisle wrote: > > > >> 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. > Understood, and apologies if that wasn't clear. But there might be > pragmatic markup whose meaning wasn't defined, or where we can think, > maybe as CDs evolve, of "better", but still mathematically equivalent, > OM. > >> Which essentially means, as I understand it, that 'condition' is > either > >> IN or OUT, irrespective of CDs. > I meant, "in strict", sorry. > > 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, > But as I understand it, the P->S would fail to convert this. Am I wrong > here? This is a key illustration. > [I'll come back to the rest later] > > 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
