FW: N-ary objects in Office Math Markup Language (OMML)

[Rex Jaeschke]

From: Francis Cave [mailto:francis at franciscave.com] 
Sent: Thursday, November 2, 2017 2:39 PM
To: 'Rex Jaeschke' <rex at RexJaeschke.com>; 'MURATA Makoto'
<eb2m-mrt at asahi-net.or.jp>
Subject: RE: N-ary objects in Office Math Markup Language (OMML)

 

Hi Rex

 

DR attached. I’ve revised the wording to fit the DR template more cleanly.

 

Kind regards,

 

Francis

 

 

 

From: Rex Jaeschke [mailto:rex at RexJaeschke.com] 
Sent: 02 November 2017 16:08
To: 'Francis Cave' <francis at franciscave.com <mailto:francis at franciscave.com>
>; 'MURATA Makoto' <eb2m-mrt at asahi-net.or.jp
<mailto:eb2m-mrt at asahi-net.or.jp> >
Subject: RE: N-ary objects in Office Math Markup Language (OMML)

 

Francis, I think you should make this a DR, so we have a formal track record
of it. How about you make it one DR, and if when we work on it we think it
makes sense to split one or more items off into separate DRs, we can do that
then.

 

Regards, Rex

 

 

From: Francis Cave [mailto:francis at franciscave.com] 
Sent: Wednesday, November 1, 2017 3:10 PM
To: 'MURATA Makoto' <eb2m-mrt at asahi-net.or.jp
<mailto:eb2m-mrt at asahi-net.or.jp> >; Rex Jaeschke <rex at RexJaeschke.com
<mailto:rex at RexJaeschke.com> >
Subject: N-ary objects in Office Math Markup Language (OMML)

 

Murata-san, Rex

 

I’ve had occasion to take a close look at §22.1 Math in 29500:2016-1.

 

There are a number of minor editorial nits in this section, but one
particular point has struck me, and I’m wondering if this is worthy of a
separate DR submission, or can be treated as an editorial nit.

 

Clause §22.1.2.70 defines the element <m:nary> (n-ary Operator Object).
Clause §15.1 defines ‘n-ary operator’ to be “An operator that involves n
terms when expanded
’. But in OMML the term n-ary applies not only to
operators such as finite series summation and series product but also to the
integral operator, which is not normally described as an n-ary operator. I
think therefore that the definition of ‘n-ary operator’ in Clause §15.1
should be changed to read something like “A mathematical operator comprising
an operator character and, optionally, expressions of a lower limit, an
upper limit, or both.”

 

Clause §22.1.2.70 itself contains a typo and also contradicts the schema.
The first paragraph should begin:

 

This element specifies an n-ary object, consisting of an n-ary
objectoperator, a base (or operand), and optional upper and lower limits.

 

In syntactic terms the word ‘optional’ contradicts the schema, in which all
the child elements <m:sub>, <m:sup> and <m:e> are mandatory. It might be
worth noting that any of these elements may be empty.

 

Editorial “nits” that I’ve spotted include:

 

*	In §22.1.2.4, the example includes “Example (OFF)” and “Example
(ON)”, which I think we clearer if these were ‘not aligned’ and ‘aligned’
respectively.
*	The term “math argument” as used in §22.1.2.5 is not defined. In
fact, there are four elements in this category: §22.1.2.26 deg, §22.1.2.32
e, §22.1.2.112 sub and §22.1.2.114 sup. They all share the same complex type
‘CT_OMathArg’. I suppose it could be argued that the term doesn’t need to be
defined, because it has the generally-accepted meaning in a mathematical
context.
*	In §22.1.2.6, the use of the term “degree argument” in the last line
of text in the example doesn’t make sense.
*	In §22.1.2.26 the second sentence contradicts the schema, as the
element <m:deg> is not optional in the schema.
*	In §22.1.2.71, two occurrences of “built down form”, which should be
“built-down form” with a hyphen.
*	The only prose specification of the element <m:sub> is in
§22.1.2.112, but this specifies a particular case, not the general case.
Either this Clause needs to be generalized, or a new Clause defining <m:sub>
in the general case needs to be added. This element occurs in many content
models in addition to <m:sPre>.
*	In §22.1.2.88 the first sentence contradicts the schema, as the
element <m:deg> is not optional in the schema. The example in §22.1.2.89
correctly shows an empty <m:deg/> element, for the case where there is no
degree object/argument in the math expression as rendered.

 

I’m happy to submit one or more DRs, if you think that appropriate.

 

Kind regards,

 

Francis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20171114/0f640b11/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DR-17-FC20171102.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 92466 bytes
Desc: not available
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20171114/0f640b11/attachment-0001.docx>