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, particularly
ones that are suggested for formal adoption by the OpenMath Society.

IMPORTANT DATES (all times are "anywhere on earth")

    * 1 June: Submission (EXTENDED)
    * 20 June: Notification of acceptance or rejection
    * 04 July: Final revised papers due
    * 11 July: Workshop

SUBMISSIONS

Submission is via EasyChair
(http://www.easychair.org/conferences?conf=om20120).  Final papers
must conform to the EasyChair LaTeX style.  Initial submissions in
this format are welcome but not mandatory – but they should be in PDF
and within the given limit of pages/words.

Submission categories:

    * Full paper: 5–10 EasyChair pages
    * Short paper: 1–4 EasyChair pages
    * CD description: 1-6 EasyChair pages; a .zip or .tgz file of the
      CDs must be attached, or a link to the CD provided.
    * Standard Enhancement Proposal: 1-10 EasyChair pages (as
      appropriate w.r.t. the background knowledge required); a .zip or
      .tgz file of any related implementation (e.g. a Relax NG schema)
      should be attached.

If not in EasyChair format, 500 words count as one page.

PROCEEDINGS

Electronic proceedings will be published with CEUR-WS.org in time for
the conference.

ORGANISATION COMMITTEE

    * Christoph Lange (University of Bremen and Jacobs University
      Bremen, Germany)
    * James Davenport (University of Bath, UK)

Comments/questions/enquiries: to be sent to om2012-0< at >easychair.org

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",
they really don't _need_ the extension to allow unitless values.
So, I personally wouldn't have a huge problem requiring some
sort of unit thing in the mpadded attributes.

Whatever makes the spec "better"! :>



For all lengths, or just for mpadded?

Thanks for your comments;
bruce

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

________________________________________________________________________
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: 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 deprecate it for length values):

http://www.w3.org/TR/css3-values/#lengths

Indeed, a relative "0" or an absolute "0" mean the same, whatever the 
unit. And in mpadded, "+0" and "-0" also mean "do not change size", 
whatever the unit or percent.

FYI, Mozilla only implements the unitless "0" (and maybe "+0" and "-0") 
but this has recently be removed to align on the MathML3 spec.

On 22/05/2012 22:11, Bruce R Miller wrote:

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 (effectively scaling the number) and an
optional pseudo-unit, by a pseudo-unit alone, or by a unit
(excepting %)", would it be clearer to replace "which may be followed" 
with "followed"?

In the text "the resulting length is the product of the number
(possibly including the %) and the following pseudo-unit, unit,
namedspace or the default value for the attribute if no such unit
or space is given", would it be clearer to replace "if no such unit
or space is given" with "if % is specified with no pseudo-unit"? 

http://www.w3.org/Math/draft-spec/chapter3.html#presm.mpadded

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 comment and at least allow switching between numeric
reference and character data. For later:-)

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-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 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

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 this anyway, so I could be persuaded it was a good
idea:-) I'll pass it past the working group.

The main disadvantage, and the reason why we changed at MathML3 to
display the numeric reference is that it means that the fragments are in
themselves not well formed. So in an HTML(5) context it is fine as the
entities are not well formed but if you cut and paste that fragment to a
system expecting MathML as well formed XML then you get a fatal parse
error. Use of numeric references avoids this (very real) problem.

chapter 7 warns about this:


Even if you are reading the html version of the spec, you may be wanting 
to use with a system requiring xml...


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

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.  Smart people will go the the MathML defining document and copy
the examples found there.  Others will then copy the code found on these
people's webpages, etc.   It is important that the MathML examples be the
best code possible.  

The HTML5 defining document has a nice named character references chart
that shows entity name, Unicode number, and a sample glyph of the character.  
http://www.whatwg.org/specs/web-apps/current-work/multipage/named-character-references.html

I am assuming most people will simply look at the chart for the character they 
want and use the entity name to add it.   To make life easier for these people
the MathML examples should use these entity names.  


The formatting changes make reading the HTML source code much easier.


Joe

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 the source) are no
longer available. I could of course change the pipeline to preserve the
names or I could just pick one of the entity names for that character.
But it may still be a bit early given browser support for html5 parsing.

The xhtml version has to use numeric references because browsers do not
fetch external dtd so it would not be well formed otherwise. the html5
spec could say that xhtml documents should be parsed with a catalog that
preloads the entities. I have an open bug on html5 requesting that, but
that is the current situation.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=13409

(but I think the bugs database is down for a while)


It validates with the validator.nu based validator at the w3c except
that the public instance of that currently uses a mathml2 schema for its
math fragment so the mathml3 features don't validate. I pinged the
maintainers of that earlier in the week and there is a development
version updates the mathml schema used so this will be fixed once that's
ready to roll out. But thanks for checking:-)

http://validator.w3.org/nu/


Ah the index, yes that's mechanically generated of course I could put
newlines rather than spaces between entries. It's never bothered me, but
I suppose some editors (or people) get a bit stressed by 56737 character
lines:-)

Yes but that file as served there is never touched by an editor or
manually changed in any way. I think that's an important property to
keep when publishing in multiple formats.
Thanks for your comments, I'll see what I can do about the formatting.

David

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 problem, but the documents' HTML code is very poorly indented and spaced.  

For example see line 24605 of the HTML5 + MATHML document 

Any decent code editor can easily assist in proper indentation and line spacing.   

     Joe

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. 
________________________________________________________________________