Re: Displaystyle and mtable

On 12/06/2014 12:50, Davide P. Cervone wrote:
>> The part that seems inconsistent to me is
>>   "They also may be set explicitly via the displaystyle and
>>   scriptlevel attributes on the mstyle element or the displaystyle
>>   attribute of mtable. In all other cases, they are inherited from
>>   the node's parent."
>> because "explicitly" here also applies to "displaystyle
>> attribute of mtable", and "all other cases" seems to imply that
>> the previous sentences form an exhaustive list.
>> A default (not explicit) attribute of mtable was not in the
>> exhaustive list.
> Yes, that is certainly a source of the inconsistency in my mind as well.
>> Perhaps removing "explicitly" might be enough to remove the
>> inconsistency.
> Yes, that would help, and David's suggestion of adding mtable to the list of elements that modify the displaystyle setting in the sentence before that would also help.  Although David indicates that this is not an exhaustive list, it appears to be an exhaustive list, particularly when the "all other cases" is taken into consideration.

Yes I think its clear that it would be (have been) better to have 
mentioned the math element in that paragraph but I think its also clear that
it is (intended to be) a helpful comment on definitions elsewhere rather 
than a normative statement  hence casual wording such as
" various script and limit schemata elements," but this is just spec 
legal arguments (basically I'm justifying classing any change to that
paragraph as editorial clarification rather than a change to the spec.)

>    Even the parenthetical statement about seeing the particular element's descriptions could be read to refer to the elements in the list just given.  The fact that mtable has a special rule for displaystyle puts it in the same category as mfrac, mroot, and the script and limit tags.  I guess the only other one not listed is mscarries, unless that is considered a scripting tag.  So adding mtable (and perhaps mscarries) would make it an exhaustive list.

yes we should probably do that.

> The fact that the default in the attribute list for mtable is set to "false" and not "inherited" is also not enough to prevent misunderstanding (as mstyle overrides lots of attributes that don't have default of "inherited")

The intention is that looking at that table _is_ enough, can you give an 
example where you think a table is wrong?

>   without a very careful reading of a complicated ruleset that is described in several different locations in the specification.  Displaystyle in particular is unusual in that it has values for each element, but can only be set via the <math> or <mstyle> tags, or the <mtable> tag.  So the "special rules" that apply to <mfrac> and <mroot> aren't a problem, because you can't specify displaystyle on these directly (so there is no ambiguity about what value of displaystyle is in effect and how that propagates to the children).  On the either hand, since <mtable> can have a displaystyle attribute, a surrounding <mstyle> should be able to set that value, just as it does for any other attribute of its children.  The exceptions are listed in the 9th paragraph of section (counting the bullets as paragraphs), and displaystyle for mtable is not listed among them.  Perhaps it should be.
> Davide

The first bullet point does explicitly note that in the case of 
displaystyle some elements set it automatically,
and the description of mtable (if not other places) does say that mtable 
does this,


Received on Thursday, 12 June 2014 13:55:46 UTC