gmane.comp.web.mathematics

Deadline Extended to 1 June: OpenMath workshop at CICM (11 July, Bremen, Germany)

Christoph LANGE — 2012-05-24T19:34:10

24th OpenMath Workshop
Bremen, Germany
11 July 2012
co-located with CICM 2012
Submission deadline (EXTENDED) 1 June

http://www.informatik.uni-bremen.de/cicm2012/cicm.php?event=openmath

OBJECTIVES

OpenMath (http://www.openmath.org) is a language for exchanging
mathematical formulae across applications (such as computer algebra
systems).  From 2010 its importance has increased in that OpenMath
Content Dictionaries were adopted as a foundation of the MathML 3 W3C
recommendation (http://www.w3.org/TR/MathML), the standard for
mathematical formulae on the Web.

Topics we expect to see at the workshop include

    * Feature Requests (Standard Enhancement Proposals) and Discussions
      for going beyond OpenMath 2;
    * Further convergence of OpenMath and MathML 3;
    * Reasoning with OpenMath;
    * Software using or processing OpenMath;
    * New OpenMath Content Dictionaries;

Contributions can be either full research papers, Standard Enhancement
Proposals, or a description of new Content Dictionaries, par

Re: unitless lengths in mpadded attributes

Frédéric WANG — 2012-05-24T09:09:49

Mozilla supports unitless for all length attributes and treats it as a 
multiple of the default (although it is not clear whether determining 
the "default" is well implemented). For mpadded, Mozilla allows unitless 
only for "0". The code contains these comments:

     // also cater for the edge case of "0" for which the unit is optional

       // no explicit CSS unit and no explicit pseudo-unit...
       // In this case, the MathML REC suggests taking ems for
       // h-unit (width, lspace) or exs for v-unit (height, depth).
       // Here, however, we explicitly request authors to specify
       // the unit. This is more in line with the CSS REC (and
       // it allows keeping the code simpler...)

In Firefox 15 (nightly build), the case "0" is now removed.

Re: unitless lengths in mpadded attributes

Neil Soiffer — 2012-05-23T19:08:51

<snip>
If any other implementors could say whether they currently allow


Since you asked...  MathPlayer supports unitless values.  E.g., width="3"
means times the default width (the width of the child).

Neil Soiffer
Senior Scientist
Design Science, Inc.
www.dessci.com
~ Makers of MathType, MathFlow, MathPlayer, MathDaisy, Equation Editor ~

Deadline extension for MathUI 2012

Paul Libbrecht — 2012-05-23T18:32:38

Dear researchers and practitioners,

Following demand, be informed that the deadline to submit a contribution to MathUI 2012 has been extended to May 30th.

...looking forward to exciting contributions!

Paul Libbrecht

Re: unitless lengths in mpadded attributes

Bruce Miller — 2012-05-23T17:28:23

 >
 >

While it may seem contradictory, we were indeed attempting
to discourage use of unit-less lengths, while allowing them
in more places!  Unit-less-ness was the tricky part of making
lengths more consistent --- the overall goal being to
reduce, not increase, ambiguity and to give authors (& implementors)
fewer simpler rules that applied across the board, rather than
having to check the documentation for every specific attribute
to see what special cases applied.


The problem is that people (at least me! :> ) also expect width="20"
to not mean randomly different things: 20pixels sometimes, 20 times
a default others. Several attributes (minsize,maxsize,linethickness...)
already had the latter interpretation in MathML 2, and some people
apparently find that useful.


That would be backwardly incompatible (in general)


Actually, the attributes for mpadded are not, strictly,
just "length" since they have the extended format with pseudo-units.
Moreover, they already allow expressions such as width="2width",

Re: unitless lengths in mpadded attributes

David Carlisle — 2012-05-23T08:27:58

Frédéric,

Thanks for your comments, I think this shows the advantages of moving
the editors' draft to public space in that people can see exactly what
changes are proposed earlier and comment if necessary:-)

As you know MathML2 wasn't always consistent in this area and
maintaining compatibility with MathML2 in "real" cases but moving
towards a more consistent treatment of lengths in mathml3 has proved tricky.

The basic "model" for lengths in mathml3 is that in most cases units may
be omitted and in that case the number is taken as a multiplier for the
specified default value. That would suggest the interpretation that we
put in the draft yesterday that unitless lengths _are_ allowed. However
you make some good points and clearly we should look again before
definitely confirming this.

If any other implementors could say whether they currently allow
unitless values on mpadded, and if so whether they just allow 0 or other
non-zero values, that would also be useful information.

David

____________________

Re: unitless lengths in mpadded attributes

Frédéric WANG — 2012-05-23T06:42:15

Here I meant to allow but deprecate non-zero unitless values.

Re: unitless lengths in mpadded attributes

Frédéric WANG — 2012-05-23T06:38:14

Unitless attributes were not allowed in mpadded in MathML2:
http://www.w3.org/TR/MathML2/chapter3.html#presm.mpadded

And I understood the goal was to deprecate unitless values.
http://www.w3.org/TR/MathML3/chapter2.html#fund.units
"A number without a unit is intepreted as a multiple of the default 
value. This form is primarily for backward compatibility and should be 
avoided, prefering explicit units for clarity."

In particular unitless values can lead to ambiguities:
http://lists.w3.org/Archives/Public/www-math/2012Jan/0030.html
http://lists.w3.org/Archives/Public/www-math/2012Jan/0031.html

For "0" (and those with  no effects "+0" and "-0") it is generally clear 
what we want. But similarly to my comment about mglyph, I think people 
would expect width="20" to behave like width="20px" not like "2000%" as 
it is recommended for length values.

Maybe it would be better (for both length and mpadded values) to do as 
in CSS: only allow unitless for "0" (or at least for backward 
compatibility, allow but de

Re: unitless lengths in mpadded attributes

Bruce R Miller — 2012-05-22T20:11:31

Indeed we had intended the "?" to allow unit-less values as we do with other
length-like attributes --- a few paragraphs later in the text you
cited describes that case --- but in the heat of sorting out reference & default
values, we left off the "?" in the regular expressions.
(and in the schemas generated from them).



Odd that we managed to mangle that as well; a unitless "0"
shouldn't have been used as the default in either case!
(it would be either invalid or circular!)


Indeed.


I think this is correct as it stands, but was intended to describe
the case where the entire percent|unit|pseudo-unit|namedspace clause
was optional.


The correction is now in the editors draft.
Thanks for bringing this up, and your attention to detail!

bruce

unitless lengths in mpadded attributes

Karl Tomlinson — 2012-05-21T21:54:03

Can get clarification of these questions in the context of mpadded
attributes, please?

1. Are unitless lengths valid attribute values?
2. Is "0" a special case where no unit is valid?

In the attribute table, the description
'( "+" | "-" )? unsigned-number (("%" pseudo-unit?) | pseudo-unit | unit | namedspace )'
has no "?" following the second set of parentheses, indicating
that there must be something following the unsigned-number.

That seems reasonably clear that the answer to both my questions
is "no", but there are some possible hints elsewhere in the spec
that unitless values might be valid, so I want to check that I am
not missing something.

The default for both lspace and voffset is "0".
I guess it's quite feasible to have a default that is not a string
that can be specified as a valid value, but it feels a little odd.

Would it be clearer to specify the default value as "0em", as it
was in MathML2?

In the text "Each format begins with an unsigned-number, which may
be followed by a % sign (effecti

Re: minor suggestions on Public Editor's draft of MathML

David Carlisle — 2012-05-18T13:07:35


Yes the exact situation is that if the original source used an entity
reference then the document production replaces the entity with a
numeric reference and adds a comment with the Unicode name. In this
latest iteration the numeric reference is wrapped in a span with the
original reference in the title, and that gives enough for the html5
version to allow the dynamic switch.

However several examples (more than I remembered actually) are entered
in the initial sources using numeric references rather than entity
references, (many of the presentation examples in chapter 4 do this as
they are semi-automatically generated from the content markup, so
numeric references are more natural to produce than entity name
references) some of those have Unicode name comments added explicitly.
In any case these ones don't currently get picked up by the new
mechanism. If we keep this we should normalise the input a bit more and
also probably allow characters entered by numeric reference to also get
the Unicode name commen

Re: minor suggestions on Public Editor's draft of MathML

David Carlisle — 2012-05-18T10:15:34



I put an experimental option so you can flip the display between entity
refs character refs and just showing the character. Note this is an
_editors' draft_ so this is just an experimental feature that might come
or go, depending how it works out. The display of the controls at the
top of the document certainly would need some adjusting.
It's too big and too cluttered as it is but I think it will do for now.

Need to work through the remaining bug reports and update the draft and
errata page, and hopefully improve the mml3tomml2 transformation so that
new mathml3 features display better in "legacy browsers" (that is,
everything except mathplayer currently.) It does an OK job except that
some mstack features are not supported and (not unrelated) mlongdiv gets
more or less messed up currently, as you can see by looking at those
examples in the spec after choosing either of the transformation options.

David

________________________________________________________________________
The Numerical Algorithms Gr

Re: minor suggestions on Public Editor's draft of MathML

Joe Java — 2012-05-17T19:38:39

Hello David,




One added bonus of using entity names over Unicode numbers is that some characters
are made up of more than one Unicode number, (ex: acE; , cups; , NotEqualTilde; , etc.)
Encoding for these characters is much easier using an entity name.  
 
Thank you for considering the changes I suggested.  


Joe

Re: minor suggestions on Public Editor's draft of MathML

David Carlisle — 2012-05-17T16:11:21


sorry that should have said:

So in an HTML(5) context it is fine as the
entities are predefined

David

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 
________________________________________________________________________

Re: minor suggestions on Public Editor's draft of MathML

David Carlisle — 2012-05-17T16:03:41


Being pedantic implies that using <mo>-</mo> is wrong, or that at least
<mo>&minus;</mo> is preferable. But I don't think it is. I think that
either is perfectly acceptable (and equivalent).


If you see a visible difference then your mathml renderer is doing it
wrong. What you describe is of course what will happen if you use the
character in plain text, as the hyphen character is typically shorter
than the minus sign. But hyphen-minus is supposed to render as a hyphen
in text and as a minus in math.



Ah. I have that installed, will check. I've been using an "opera labs"
version as well so I may have got confused. I'd also need to check what
happens on (say) IE8.


well yes, which is why I thought now was a good time to release this
version, but still not everyone is running the latest browser so it's
good to use the html5 features where they fall back gracefully.

Hixie generates that from the same unicode.xml file that sits behind
this document and the xml entities document.


As I say I nearly did th

Re: minor suggestions on Public Editor's draft of MathML

Joe Java — 2012-05-17T15:24:46

Hello David,




Realistically, the vast majority of people will use the hypen-minus character, 
but the defining document for MathML should be pedantic and use the 
defined minus character.  Most people do not even know that the hypen-minus 
character is not the same size as the minus character.  To see this, place text on 
both sides of a plus character then toggle the plus character with a minus sign.  
If you use the hypen-minus character the text around the minus will move, but
if you use the minus character, it will not move.  The hypen-minus character is 
smaller than the minus character.  The minus character is defined to be the same 
width as the plus character.



Latest Opera seems to have all the pre-defined HTML5 entities.


Browser support of HTML5 is actually pretty good.  

I am assuming most new MathML on the web will be in HTML5 documents.
Most people wanting to add some MathML to their webpage will just
find a formula similar to what they want to use and cut and past the 
code.  Sma

Re: minor suggestions on Public Editor's draft of MathML

David Carlisle — 2012-05-17T11:27:18

Sorry about that. My previous comments were true but missed an important
detail that the lines in mathml.html were much worse than the lines in
the separate xhtml files from which it is derived. That was an oversight
in the stylesheet doing the conversion (or more exactly in the way it
was invoked) I fixed that and a few long lines occurring explicitly in
our sources and now

$ egrep ".{400}" mathml.html | wc -l
9

That is, there are only 9 lines with more than 400 characters. Mostly
they are alt texts with long TeX expressions for the images, and a
couple in the schema chapter.

David

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 
__________________________________________________________

Re: minor suggestions on Public Editor's draft of MathML

David Carlisle — 2012-05-16T21:44:54

I have just updated the stylesheets with some additional newlines and now

  egrep ".{2500}" mathml.html

reports there are no lines longer than 2500.

That's probably still a bit large but better than 56 thousand. But it 
gets progressively harder to catch the other cases. Many sections are 
generated from one thing or another and changing the generation can have 
unwanted side effects. We can't just indent the final file as there are 
places where white space is significant and unless the tool fully knows 
the semantics of html, mathml, relaxng and xsd regexp syntax, then just 
wrapping long lines and indenting is bound to break something:-)

However I'll try and keep an eye on it so that the line length comes 
down rather than going up as edits are made.

David

Re: minor suggestions on Public Editor's draft of MathML

David Carlisle — 2012-05-16T20:30:15

Yes and no, I think it's no bad thing to show that + and - can be types
just on an ASCII keyboard, and also of course using - gives a little
test of your renderer, using " & m i n u s ;" makes it too easy:-)

Perhaps or perhaps not. I could be persuaded either way but I'm inclined
to stick with - but this reply is a personal response the WG might
agree. It would be simple enough to change the sources. Perhaps we
should change some of them...


I wondered about that in the html version but....
For older browsers (including current Opera unless you have a test
version I think) that do not pre-define the full html5 entity set the
characters would be mis-parsed if I used entity references.

Also it's technically easier for me to use the expanded form (although
that's no excuse really and I could change this if necessary) but new
html5 version is actually a post-processed version of the xhtml version
and that has to have the numeric references rather than entity
references, so the entity names (which are used in

minor suggestions on Public Editor's draft of MathML

Joe Java — 2012-05-16T19:34:04

Nit-picking at the latest MATHML editors draft


1.  Some of the examples appear to use theHyphen-minus (&#x002D;) instead of the &minus; (&#x2212;) character
to represent the minus sign.  For an example see "3.5.5.8 MathML representation of an alignment example" in the editors draft.  

Section "7.7.1.1 Minus" does say that MathML renderers should treat Hyphen-minus as a minus sign, 

but perhaps the defining document of MathML should use the correct character defined as the minus sign.

2. The examples use the Unicode number followed by a commented out long Unicode name for non-ASCII characters.
Now that the "XML Entity Definitions for Characters" is out and the latest HTML5 draft has a table of all the character entity names,
it might be better to only have the entity names used rather than the Unicode number of the non-ASCII characters/entities.

3.  The document HTML5 + MATHML (http://www.w3.org/Math/draft-spec/mathml.html) does not validate with the W3C validator.  

It would be easy to fix this p

Re: Minor problems found in MathML 3 specification

David Carlisle — 2012-05-16T09:17:09

Andrew,
Thanks again for these comments and the later reports that you made.

As you have probably seen we've just made the editor's draft public. 
Hopefully all your comments have either been addressed or added as 
editors notes in the change log to be addressed next.

http://www.w3.org/Math/draft-spec/appendixf-d.html#changes.mathml3.02e-3.0

David


________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 
________________________________________________________________________