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

[Robert Miner]

Hi.

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 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 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.  It means that in all likelihood, OM3 and strict content MML won't be isomorphic, but if the mapping is straightforward enough, most of the benefit is still achieved.

In any event, the proposals on the table from James and Michael are either to use complex binding constructs, or to define a whole bunch of symbols like 'prodcond' that take a condition as an argument.  For those proposals, I think your assertions break down:

> - it makes it easy to translate condition and domain-of-application
> elements which were in many places in MathML-content-2

Not really.  The complex binding constructs are going to be hard to algorithmically assemble from all the different combinations of qualifiers in different orders, etc that XSLT is going to have to pattern match.  The 'prodcond' proposal is much worse, as these symbols don't exist yet, so what would I put in the "strict equivalents" section?

> - it's an extension that seems easy to manage in a set of XSLT: any
> match for ombind is enriched with a check on cardinality 2, probably a
> single template can do it for ombind of three children applying
> templates on a rephrased object (that might need an extension).

It isn't the OM -> XXX direction that is hard.  It is the pragmatic -> strict mapping that is hard.

> But unfortunately, I'm neither David's XSLTs author, nor an active
> writer in chap 4 so my voice maybe does not count.
> Under my own perspective, I promise it would help readability and
> writable of a lot of expressions.

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.

> I felt convinced by, indeed, the lack of activity of OM3, even though
> James' activity can't be said to be zero. But really, it is a pure
> extension where only erroneous objects would be endowed with a new
> semantic.
> 
> Calling this backward-incompatible is as wrong as calling this a
> breaking change, it is breaking errors!

I acknowledge this point, at least from the MathML point of view.  But I believe what that says is it would be okay to finish MathML 3 with strict content MathML basically isomorphic to OM2, and leave the mapping to an extended OM3 to OpenMath in the future, whenever OM3 is actually done.

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.

--Robert


> -----Original Message-----
> From: Paul Libbrecht [mailto:paul at activemath.org]
> Sent: Tuesday, March 24, 2009 7:56 AM
> To: Robert Miner
> Cc: 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
> 
> 
> Le 23-mars-09 à 18:05, Robert Miner a écrit :
> > 2) The two-stage translation of qualifiers into a domain of
> > application,
> > and thence into OM may not be ideal, but we know it is
> >  a) as mathematically meaningful as anything else,
> >  b) is most compatible with the bulk of the current text in Ch 4
> >  c) compatible with the large amount of XSLT David has developed over
> > many years
> >  d) backwardly compatible with MML2/OM2
> 
> I have the exact opposite feelings here about the addition of a
> condition child to bind/ombind:
> - it makes it easy to translate condition and domain-of-application
> elements which were in many places in MathML-content-2
> - it's an extension that seems easy to manage in a set of XSLT: any
> match for ombind is enriched with a check on cardinality 2, probably a
> single template can do it for ombind of three children applying
> templates on a rephrased object (that might need an extension).
> 
> But unfortunately, I'm neither David's XSLTs author, nor an active
> writer in chap 4 so my voice maybe does not count.
> Under my own perspective, I promise it would help readability and
> writable of a lot of expressions.
> 
> > 3) A change to something such as Michael and James have proposed
> > is[...]
> >  d) is not backward compatible, and would introduce a heavy
> dependency
> > in MML3 on OM3, even though the latter shows no sign of being done
> > any time
> > soon.
> 
> I felt convinced by, indeed, the lack of activity of OM3, even though
> James' activity can't be said to be zero. But really, it is a pure
> extension where only erroneous objects would be endowed with a new
> semantic.
> 
> Calling this backward-incompatible is as wrong as calling this a
> breaking change, it is breaking errors!
> 
> paul