Planet MathML - W3Chttp://www.w3.org/Math/planet/atom.xml2014-12-22T03:31:39+00:00Planet/2.0 +http://www.planetplanet.orgHighWire continues as MathJax Supporterhttp://www.mathjax.org/?p=58232014-12-19T09:46:15+00:00<p><a href="http://home.highwire.org/">The HighWire Open Platform</a> provides innovative technology solutions to influential societies, university presses, and independent publishing organizations, assisting in the digital dissemination and readability of some of the most high-impact journals, books, and other scholarly materials on the net.</p>
<p>“As a pioneer in online journals, HighWire has been a strong supporter of initiatives such as the development of MathJax’s open source platform for display of mathematics,” said Xenia Siller, VP, Platform and Content Solutions, HighWire Press. “The HighWire Open Platform is designed to work well with standards such as MathML to ensure accurate dissemination and elegant user experiences across devices and output channels. We’re proud to be part of the solution for readers.”</p>
<p>“As a MathJax sponsor, HighWire provides the MathJax team with important feedback for our development,” comments Peter Krautzberger, MathJax manager. “Thanks to dedicated sponsors like HighWire we can keep MathJax the high-quality, reliable, and flexible rendering solution it is today.”</p>
<p>We look forward to continuing the collaboration with HighWire and welcome their ongoing support for the MathJax project.</p>MathJaxhttp://www.mathjax.orgProject Euclid continues as a MathJax Supporterhttp://www.mathjax.org/?p=58812014-12-15T20:45:05+00:00<p><a href="http://projecteuclid.org">Project Euclid</a> continues to support the MathJax project as a MathJax Supporter.</p>
<p>Project Euclid is a not-for-profit online publishing service designed to address the unique needs of the fields of theoretical and applied mathematics and statistics by providing access to independent and society journals, monographs, and conference proceeding. Through a collaborative partnership arrangement, publishers join forces and participate in an online presence with advanced functionality, allowing them to better serve scholars without sacrificing their intellectual or economic independence or commitment to low subscription prices. Project Euclid is jointly managed by <a href="https://www.library.cornell.edu/">Cornell University Library</a> and <a href="http://www.dukeupress.edu/">Duke University Press</a>.</p>
<p>“We initially implemented MathJax on twenty titles, since then we have significantly expanded its use on Project Euclid” says Mira Waller, Director of Publishing Services. “MathJax has become an important part of Project Euclid’s display of math on the web and we are proud to continue our support of this valuable service.”</p>
<p>“The continued support of Project Euclid demonstrates its commitment to being a partner to the science community on the web”, comments Peter Krautzberger, MathJax Manager. “The feedback of sponsors such as Project Euclid is invaluable to ensure that MathJax remains the reliable, high-quality rendering solution it is today.”</p>
<p>The MathJax team looks forward to the continued collaboration with Project Euclid, and welcomes their ongoing support for the MathJax project.</p>MathJaxhttp://www.mathjax.orgRe: Fwd: FW: Problem with MathML3 schemamid:5486D678.2060405@nag.co.uk2014-12-09T11:01:12+00:00<div>
<pre id="body">
<a shape="rect" accesskey="j" id="start10" name="start10"></a>On 08/12/2014 20:42, Autumn Cuellar wrote:
> Hi,
>
> Tom Magliery at JustSystems seems to have spotted an issue in the MathML
> 3 Schema. I believe he's correct but wouldn't claim to be an XML Schema
> expert. What say you?
>
> Thanks,
> Autumn
>
> *From:* Tom Magliery [mailto:<a shape="rect" href="mailto:tom.magliery@justsystems.com?Subject=Re%3A%20Fwd%3A%20FW%3A%20Problem%20with%20MathML3%20schema&In-Reply-To=%3C5486D678.2060405%40nag.co.uk%3E&References=%3C5486D678.2060405%40nag.co.uk%3E">tom.magliery@justsystems.com</a>
> <mailto:<a shape="rect" href="mailto:tom.magliery@justsystems.com?Subject=Re%3A%20Fwd%3A%20FW%3A%20Problem%20with%20MathML3%20schema&In-Reply-To=%3C5486D678.2060405%40nag.co.uk%3E&References=%3C5486D678.2060405%40nag.co.uk%3E">tom.magliery@justsystems.com</a>>]
> *Sent:* Friday, December 05, 2014 4:16 PM
> *To:* Autumn Cuellar
> *Subject:* Problem with MathML3 schema____
>
> __ __
>
> Hi Autumn,____
>
> __
>
> __
>
> We think there's an invalid definition in the XSD for MathML 3. The
> issue occurs within mathml3-strict-content.xsd.____
>
> <a shape="rect" href="http://www.w3.org/Math/XMLSchema/mathml3/">http://www.w3.org/Math/XMLSchema/mathml3/</a>____
>
> On line 65, they define a group, “semantics-ci” and that group includes
> itself on line 72; according to our understanding of XSD this is not
> allowed:____
>
> __ __
>
> ---------------------------------------------------------------------------------____
>
> <a shape="rect" href="http://www.w3.org/TR/xmlschema-1/#coss-modelGroup">http://www.w3.org/TR/xmlschema-1/#coss-modelGroup</a>____
>
> __ __
>
> 2 Circular groups are disallowed. That is, within the {particles} of a
> group there must not be at any depth a particle whose {term} is the
> group itself.____
>
> ---------------------------------------------------------------------------------____
>
> __ __
>
> I guess I'll start with: are we misunderstanding something?____
>
> __ __
>
> The XSDs are not normative for MathML, but this sure seems like an error
> that someone would have discovered before. (Then again, I have been on
> the DITA TC long enough to understand/believe that something like this
> could happen.)____
>
> __ __
>
> mag____
>
Hmm reading the XSD spec (always a delight:-) it seems you are right.
I'd be interested to know how you spotted that? Thanks.
The construct is generated by trang as a translation from a recursive
pattern in the Relax NG. Trang can not translate everything and already
the conversion pipeline has some transformations that simplify the Relax
NG before doing the translation. So we could add another....
It seems it got missed because XSV and xmllint -schema (xerces) both
not only accept the schema without warning, they validate using this
construct as intended. So before changing the MathML schema I may make
some enquiries to check the XSD spec does mean to say what it appears to
say. (I am certainly no expert in XSD schema).
The intention was to make <semantics> have a context sensitive content
model so that the first child is only allowed to be semantics again,
or an element that would have been allowed at that point without the
semantics (ci here).
The simplest fix is to drop that and make the same rule as in the DTD
that the first child of semantics can be any MathML (and leave further
requirements to the text of the spec and the relax NG).
Specifically you can change the definition to
<xs:group name="semantics-ci">
<xs:choice>
<xs:element ref="m:ci"/>
<xs:group ref="m:semantics"/>
</xs:choice>
</xs:group>
That successfully validates
<math xmlns="<a shape="rect" href="http://www.w3.org/1998/Math/MathML">http://www.w3.org/1998/Math/MathML</a>">
<bind>
<csymbol>forall</csymbol>
<bvar>
<semantics>
<ci>x</ci>
<annotation></annotation>
</semantics>
</bvar>
</bind>
</math>
but it no longer enforces that the content of bvar is a ci, possibly
annotated, and this would be valid to the XSD (as it is to the DTD)
<math xmlns="<a shape="rect" href="http://www.w3.org/1998/Math/MathML">http://www.w3.org/1998/Math/MathML</a>">
<bind>
<csymbol>forall</csymbol>
<bvar>
<semantics>
<cn>2</cn> <!-- cn here -->
<annotation></annotation>
</semantics>
</bvar>
</bind>
</math>
But with the schema as it currently both XSV and xerces declare the
first one valid and the second invalid.
David
</pre>
</div>David Carlisledavidc@nag.co.ukhttp://lists.w3.org/Archives/Public/www-math/Fwd: FW: Problem with MathML3 schemamid:CAB5TOv04dAJZEB-UfPFawyx+mSDvJnEDhjK3oGyeuD_eZc_4pQ@mail.gmail.com2014-12-08T20:42:39+00:00<div>
<pre id="body">
<a shape="rect" accesskey="j" id="start9" name="start9"></a>Hi,
Tom Magliery at JustSystems seems to have spotted an issue in the MathML 3
Schema. I believe he's correct but wouldn't claim to be an XML Schema
expert. What say you?
Thanks,
Autumn
*From:* Tom Magliery [mailto:<a shape="rect" href="mailto:tom.magliery@justsystems.com?Subject=Re%3A%20Fwd%3A%20FW%3A%20Problem%20with%20MathML3%20schema&In-Reply-To=%3CCAB5TOv04dAJZEB-UfPFawyx%2BmSDvJnEDhjK3oGyeuD_eZc_4pQ%40mail.gmail.com%3E&References=%3CCAB5TOv04dAJZEB-UfPFawyx%2BmSDvJnEDhjK3oGyeuD_eZc_4pQ%40mail.gmail.com%3E">tom.magliery@justsystems.com</a>]
*Sent:* Friday, December 05, 2014 4:16 PM
*To:* Autumn Cuellar
*Subject:* Problem with MathML3 schema
Hi Autumn,
We think there's an invalid definition in the XSD for MathML 3. The issue
occurs within mathml3-strict-content.xsd.
<a shape="rect" href="http://www.w3.org/Math/XMLSchema/mathml3/">http://www.w3.org/Math/XMLSchema/mathml3/</a>
On line 65, they define a group, “semantics-ci” and that group includes
itself on line 72; according to our understanding of XSD this is not
allowed:
---------------------------------------------------------------------------------
<a shape="rect" href="http://www.w3.org/TR/xmlschema-1/#coss-modelGroup">http://www.w3.org/TR/xmlschema-1/#coss-modelGroup</a>
2 Circular groups are disallowed. That is, within the {particles} of a
group there must not be at any depth a particle whose {term} is the group
itself.
---------------------------------------------------------------------------------
I guess I'll start with: are we misunderstanding something?
The XSDs are not normative for MathML, but this sure seems like an error
that someone would have discovered before. (Then again, I have been on the
DITA TC long enough to understand/believe that something like this could
happen.)
mag
</pre>
</div>Autumn Cuellarautumn.cuellar@gmail.comhttp://lists.w3.org/Archives/Public/www-math/Re: Ideas for future improvementsmid:5481892B.2040502@free.fr2014-12-05T10:30:03+00:00<div>
<pre id="body">
<a shape="rect" accesskey="j" id="start8" name="start8"></a>Le 05/12/2014 09:05, William F Hammond a écrit :
> Not if the fences wind up being constructed with CSS as enhanced
> border decorations (somewhat beyond what is presently available in
> CSS) with precise effortless stretching as a bonus. Having the fence
> specs in <mo>'s would be awkward for that.
This won't work for the "separator" attribute or for general Unicode
characters that don't have a CSS border definition. And we still need to
implement stretchy rules anyway, so using CSS is only helpful for the
simplest cases like those of Opera's stylesheet.
> Moreover, the fence operators are not semantically the same as other
> operators, and there is no definitive way to tell whether operators
> that are fence-like first and last children in <mrow> are really there
> as fences. For example, in [f(x)]_{x=a}^{x=b} (which resolves as math
> to f(b)-f(a)) the brackets are non-fence operators. Of course,
> presentation mathml is semantically poor from the outset, but this
> doesn't mean that whatever semantics are there should be trashed.
Then I believe you are doing something wrong. The spec says that "any
|mfenced| element is completely equivalent to an expanded form described
below" and "In particular, authors cannot be guaranteed that MathML
preprocessors won't replace occurrences of mfenced with equivalent
expanded forms. ". So if you want to preserve any kind of semantics you
should use a "class" attribute or a <semantics> element with parallel
markup and not rely on a presentation element name.
> Don't forget that there are many implementations other than browser
> rendering, both for generating mathml and for consuming it. If people
> believe that MathML documents are not durable at least for the extent
> of their lifetimes, they will run from MathML. [...] It would also
> break the paradigm of XML. A document spec-ed as XHTML 1 + MathML 2
> should be durable forever. [...] BTW, I believe there has been this
> debate about <mfenced> virtually from the beginning of mathml.
What you say makes sense, but it's probably this kind of reasoning that
makes MathML not attractive to Web browser companies.
--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic
</pre>
</div>Frédéric WANGfred.wang@free.frhttp://lists.w3.org/Archives/Public/www-math/Re: Ideas for future improvementsmid:i7h9xaa5dl.fsf@hilbert.math.albany.edu2014-12-05T08:05:26+00:00<div>
<pre id="body">
<a shape="rect" accesskey="j" id="start7" name="start7"></a>Frédéric WANG <<a shape="rect" href="mailto:fred.wang@free.fr?Subject=Re%3A%20Ideas%20for%20future%20improvements&In-Reply-To=%3Ci7h9xaa5dl.fsf%40hilbert.math.albany.edu%3E&References=%3Ci7h9xaa5dl.fsf%40hilbert.math.albany.edu%3E">fred.wang@free.fr</a>> writes:
> - The structure is quite different because the operators in <mfenced>
> are in attribute values rather than in elements. As a consequence,
> native implementations need to create anonymous frames to represent
> these operators.
Not if the fences wind up being constructed with CSS as enhanced border
decorations (somewhat beyond what is presently available in CSS) with
precise effortless stretching as a bonus. Having the fence specs
in <mo>'s would be awkward for that.
Moreover, the fence operators are not semantically the same
as other operators, and there is no definitive way to tell
whether operators that are fence-like first and last
children in <mrow> are really there as fences. For example,
in [f(x)]_{x=a}^{x=b} (which resolves as math to f(b)-f(a))
the brackets are non-fence operators. Of course,
presentation mathml is semantically poor from the outset,
but this doesn't mean that whatever semantics are there
should be trashed.
> - Deprecating will not break conforming implementations (they implement
> the two versions, as currently required by the spec) but only poor
> implementations like the one that used to be in Opera. As said by
> William, the only risk is breaking old documents.
Don't forget that there are many implementations other than browser
rendering, both for generating mathml and for consuming it.
If people believe that MathML documents are not durable at least for
the extent of their lifetimes, they will run from MathML.
Don't we remember the breakage in Firefox when <mlabeledtr>
was pulled from Firefox? It had consequences. Yes, that
element was of limited use, but it had some use, some were
using it, and they were annoyed.
> What I'm proposing is that browsers display a deprecation
> warning and encourage people to move to the equivalent
> version, to prepare future removal in a (very) long term.
It would also break the paradigm of XML. A document spec-ed as
XHTML 1 + MathML 2 should be durable forever.
BTW, I believe there has been this debate about <mfenced>
virtually from the beginning of mathml.
-- Bill
</pre>
</div>William F Hammondhammond@csc.albany.eduhttp://lists.w3.org/Archives/Public/www-math/Re: Ideas for future improvementsmid:548014D8.1040503@free.fr2014-12-04T08:01:28+00:00<div>
<pre id="body">
<a shape="rect" accesskey="j" id="start6" name="start6"></a>Le 03/12/2014 23:29, Murray Sargent a écrit :
> <nary> has three arguments: two limits and a n_aryand, whereas the pot pourri tags don't identify the n-aryand.
In MathML this is <munderover>A B C</munderover>
where A is an <mo> with property "largeop" (explicitly or from the
operator dictionary). The "movablelimits" of the <mo> property indicates
whether they should become subsup in inline mode.
(I agree having <mover></mover> and <munder></munder> seems a bit
duplicate, but in Gecko we end up merging the implementations, which
does not seem trivial with <mfenced>)
> A delimiter object is handy since you measure its contents and then display the result with brackets that fit (according to special rules)
<mfenced> is equivalent to <mrow> as specified by the MathML spec.
Again, you need to use the operator dictionary to determine whether the
first and last child are stretchy / fences. This just need some
additional verifications on the first and last child, but that won't
make layout or a11y algorithms harder.
> For the same reason, I prefer <mfract> to <mrow>...<mo>/</mo>...</mrow>. We use nontrivial code to convert the inline versions to the prefix versions.
This is <mfrac bevelled="true"> in MathML.
> In any event, this is all water over the dam. Deprecating any Presentation MathML tags would break too many implementations.
<mfenced> is different to what you mention above:
- The spec explicitly indicates the equivalent markup and requires the
implementation to render the two versions exactly the same. You can not
choose the one version you prefer, so implementers have double work.
- The structure is quite different because the operators in <mfenced>
are in attribute values rather than in elements. As a consequence,
native implementations need to create anonymous frames to represent
these operators.
- Deprecating will not break conforming implementations (they implement
the two versions, as currently required by the spec) but only poor
implementations like the one that used to be in Opera. As said by
William, the only risk is breaking old documents. What I'm proposing is
that browsers display a deprecation warning and encourage people to move
to the equivalent version, to prepare future removal in a (very) long term.
--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic
</pre>
</div>Frédéric WANGfred.wang@free.frhttp://lists.w3.org/Archives/Public/www-math/Re: Ideas for future improvementsmid:CABqxo81a+g8Ft96OYhmV7wwqjTHYLXweK1exCm7dohNgXmALtg@mail.gmail.com2014-12-04T07:54:47+00:00<div>
<pre id="body">
<a shape="rect" accesskey="j" id="start5" name="start5"></a>> In any event, this is all water over the dam. Deprecating any
Presentation MathML tags would break too many implementations.
In the context of browser implementations, there are not many
implementations to "break", especially if such ideas end up helping browser
vendors to actually implement MathML. Converting to such a "restricted"
profile seems trivial.
Peter.
On Wed, Dec 3, 2014 at 11:29 PM, Murray Sargent <
<a shape="rect" href="mailto:murrays@exchange.microsoft.com?Subject=Re%3A%20Ideas%20for%20future%20improvements&In-Reply-To=%3CCABqxo81a%2Bg8Ft96OYhmV7wwqjTHYLXweK1exCm7dohNgXmALtg%40mail.gmail.com%3E&References=%3CCABqxo81a%2Bg8Ft96OYhmV7wwqjTHYLXweK1exCm7dohNgXmALtg%40mail.gmail.com%3E">murrays@exchange.microsoft.com</a>> wrote:
> Re <mfenced> I think it should be kept and I'd prefer if <mnary> were used
> instead of the pot pourri <msup>, <msub>, <msubsup>, <mover>, <munder>,
> <munderover> for n-ary expressions. In OMML, there's <d> (essentially
> <mfenced>) for delimited objects (parenthetical/bracketed expressions) and
> there's <nary> for n-ary expressions. <nary> has three arguments: two
> limits and a n_aryand, whereas the pot pourri tags don't identify the
> n-aryand. OMML is an XML where you know from the opening tag what the
> object is, whereas Presentation MathML needs sophisticated parsing much
> along the lines needed for the Unicode plain text encoding of mathematics (
> <a shape="rect" href="http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf">http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf</a>). In fact,
> the Microsoft Office MathML parser uses the rich-text string stack
> originally developed for building up plain-text math content.
>
> The main math layout ideas are documented in The TeXbook in Appendix G. In
> particular, you have objects with arguments and you measure the arguments
> (recursively) and place them along with lines, etc. as needed for the
> objects. A delimiter object is handy since you measure its contents and
> then display the result with brackets that fit (according to special
> rules). The inline approach seems more complicated to me. At least it
> requires a different approach from objects such as <menclose>. For the same
> reason, I prefer <mfract> to <mrow>...<mo>/</mo>...</mrow>. We use
> nontrivial code to convert the inline versions to the prefix versions.
>
> In any event, this is all water over the dam. Deprecating any Presentation
> MathML tags would break too many implementations.
>
> Murray
>
</pre>
</div>Peter Krautzbergerpeter.krautzberger@mathjax.orghttp://lists.w3.org/Archives/Public/www-math/RE: Ideas for future improvementsmid:586abcfc5f4544e7bba377b7f15b43fb@DFM-TK5MBX15-06.exchange.corp.microsoft.com2014-12-03T22:29:13+00:00<div>
<pre id="body">
<a shape="rect" accesskey="j" id="start4" name="start4"></a>Re <mfenced> I think it should be kept and I'd prefer if <mnary> were used instead of the pot pourri <msup>, <msub>, <msubsup>, <mover>, <munder>, <munderover> for n-ary expressions. In OMML, there's <d> (essentially <mfenced>) for delimited objects (parenthetical/bracketed expressions) and there's <nary> for n-ary expressions. <nary> has three arguments: two limits and a n_aryand, whereas the pot pourri tags don't identify the n-aryand. OMML is an XML where you know from the opening tag what the object is, whereas Presentation MathML needs sophisticated parsing much along the lines needed for the Unicode plain text encoding of mathematics (<a shape="rect" href="http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf">http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf</a>). In fact, the Microsoft Office MathML parser uses the rich-text string stack originally developed for building up plain-text math content.
The main math layout ideas are documented in The TeXbook in Appendix G. In particular, you have objects with arguments and you measure the arguments (recursively) and place them along with lines, etc. as needed for the objects. A delimiter object is handy since you measure its contents and then display the result with brackets that fit (according to special rules). The inline approach seems more complicated to me. At least it requires a different approach from objects such as <menclose>. For the same reason, I prefer <mfract> to <mrow>...<mo>/</mo>...</mrow>. We use nontrivial code to convert the inline versions to the prefix versions.
In any event, this is all water over the dam. Deprecating any Presentation MathML tags would break too many implementations.
Murray
</pre>
</div>Murray Sargentmurrays@exchange.microsoft.comhttp://lists.w3.org/Archives/Public/www-math/The London Mathematical Society continues as MathJax supporterhttp://www.mathjax.org/?p=58772014-12-03T16:01:26+00:00<p>The <a href="http://lms.ac.uk/">London Mathematical Society</a> continues to support MathJax as a MathJax Supporter.</p>
<p>The London Mathematical Society (LMS) is the major UK learned society for mathematics with a nationwide and international membership. The LMS offers a rich publishing program, provides a diverse grant program, and organizes scientific meetings and lectures. Beyond that, the LMS contributes to public debate on matters affecting mathematics and mathematics education.</p>
<p>“LMS offers MathJax full-text HTML as an alternative to PDF on five of its journals and is preparing to implement it on further journals.” comments Dr. Ola Tornkvist,<br />
Managing Editor, LMS, “Feedback from readers has been positive, focusing on improved navigation and ease of access when looking something up in a paper. The LMS is pleased to continue to support the MathJax project.“</p>
<p>“Thanks to our dedicated sponsors like the LMS, we are able to develop MathJax continuously,” comments Peter Krautzberger, MathJax manager. “We are grateful for the continued support which allows us to keep MathJax the high-quality and universal rendering solution it is today”.</p>
<p>We look forward to continuing the collaboration with the LMS, and welcome their ongoing support for the MathJax project.</p>MathJaxhttp://www.mathjax.orgRe: Ideas for future improvementsmid:547EC5F2.3030703@free.fr2014-12-03T08:12:34+00:00<div>
<pre id="body">
<a shape="rect" accesskey="j" id="start3" name="start3"></a>Le 03/12/2014 08:07, William F Hammond a écrit :
> But (1) the markup is actually richer with it,
What do you mean by richer? It duplicates an existing feature and so
does not bring anything more from my point of view. Do you also want to
introduce <combination>...</combination> as a shorthand for <mfrac
linethickness="0px">?
> (2) it is convenient in the way that you observe [consistent with the
> what-wg sense of convenience], and
I said it was convenient for bad implementation of MathML ; I don't
think this should be a motivation to keep it.
> (3) it's an additional hook for CSS, that is helpful.
<mfenced> uses attributes, which make it bad for CSS styling of
individual separators / fences compared to the expanded form (or even
bad to apply MathML attributes to these elements). So I'm not sure what
you mean here.
> Also deprecation usually precedes removal, and removal would break old
> documents. -- Bill
That's the point, although I'm sure the MathML WG will be willing to
keep it for this kind of reason. The removal is for the long term
(several years). In my opinion it should have been deprecated long ago.
Anyway, I expect that <mfenced> can be implemented using shadow tree and
Web components so that it could be dropped from native MathML
implementations, without breaking existing old documents.
--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic
</pre>
</div>Frédéric WANGfred.wang@free.frhttp://lists.w3.org/Archives/Public/www-math/Re: Ideas for future improvementsmid:i7vblttdnm.fsf@hilbert.math.albany.edu2014-12-03T07:07:09+00:00<div>
<pre id="body">
<a shape="rect" accesskey="j" id="start2" name="start2"></a>Frédéric WANG <<a shape="rect" href="mailto:fred.wang@free.fr?Subject=Re%3A%20Ideas%20for%20future%20improvements&In-Reply-To=%3Ci7vblttdnm.fsf%40hilbert.math.albany.edu%3E&References=%3Ci7vblttdnm.fsf%40hilbert.math.albany.edu%3E">fred.wang@free.fr</a>> writes:
> * <mfenced> should be deprecated as it duplicates its equivalent
> <mrow>+<mo> expansion and thus adds more code to implementation. For
> native implementation like WebKit/Gecko this typically means creating
> many anonymous frames (for separators and open/close). This is a mess to
> make the mfenced rendering 100% equivalent to the <mrow>+<mo> expansion,
> to handle edge cases when parsing the attributes or to manage memory
> allocation/desallocation after dynamic changes. It seems that the only
> reason for this element is that it is a convenient shorthand for
> rudimentary implementations that don't know about the operator
> dictionary or have bad mo support in general (in some a11y tools or in
> Opera Presto).
I think <mfenced> should be kept without deprecation. I
know that the spec makes it no different from
<mrow>+<mo> for native rendering. But (1) the markup is
actually richer with it, (2) it is convenient in the way
that you observe [consistent with the what-wg sense of
convenience], and (3) it's an additional hook for CSS, that
is helpful. Also deprecation usually precedes removal, and
removal would break old documents.
-- Bill
</pre>
</div>William F Hammondhammond@csc.albany.eduhttp://lists.w3.org/Archives/Public/www-math/HTML5 Standard Brings Many Useful Featureshttp://ct.moreover.com/?a=19735665337&p=1cb&v=1&x=3aO0vn1GREVhc7Q9lBIQ2Q2014-12-02T20:24:00+00:00<table width="100%"><tr><td width="99%" valign="top">
TMC Net - <b>Found Dec. 2, 2014</b><br />... minimize plugins, including functionality for displaying vector graphics (SVG files) and mathematical notations (MathML), the new element for...<br />
</td><td width="1%" valign="top">
</td></tr></table>Ask.com News Search for "mathml"http://www.ask.com/news?q=mathmlCICM 2015: Call for Workshopsmid:20141202181514.271922430307@gigondas.local2014-12-02T18:15:14+00:00<div>
<pre id="body">
<a shape="rect" accesskey="j" id="start1" name="start1"></a> Call for Workshop Proposals
CICM 2015 - Conference on Intelligent Computer Mathematics
July 13-17, 2015
The George Washington University, Washington, D.C , USA
<a shape="rect" href="http://www.cicm-conference.org/2015">http://www.cicm-conference.org/2015</a>
----------------------------------------------------------------------
As computers and communications technology advance, greater
opportunities arise for intelligent mathematical computation. While
computer algebra, automated deduction, mathematical publishing and
novel user interfaces individually have long and successful histories,
we are now seeing increasing opportunities for synergy among these
areas. The Conference on Intelligent Computer Mathematics (CICM)
offer a venue for discussing these areas and their synergy.
CICM has been held annually as a joint meeting since 2008, colocating
related conferences and workshops to advance work in these subjects.
Previous meetings have been held in Birmingham (U.K. 2008), Grand Bend
(Canada 2009), Paris (France 2010), Bertinoro (Italy 2011), Bremen
(Germany 2012), Bath (U.K. 2013) and Coimbra (Portugal, 2014).
This is a call for proposals for workshops to be held at CICM 2015,
which will be held in Washington D.C. (USA), July 13-17 next year.
The principal tracks of the 2015 meeting will be
Calculemus (Symbolic Computation and Mechanised Reasoning)
DML (Towards a Digital Mathematics Library)
MKM (Mathematical Knowledge Management)
Systems and Data
Some of the workshops that have been held at past CICM meetings are:
Automated Reasoning: Bridging the Gap between Theory and Practice
Compact Computer Algebra
Empirically Successful Automated Reasoning for Mathematics
Intelligent Proof Search
Mathematical user Interfaces
OpenMath
Pen-Based Mathematical Computation
Programming languages for Mechanized Mathematics Systems
SCIEnce
The Notion of Proof
Proposals for workshops to be held at CICM 2015 are solicited. Both
well-established workshops and newer or brand new ones are encouraged.
Please provide the following information:
+ Workshop title.
+ Names and affiliations of organizers.
+ Brief description of workshop goals and/or topics.
+ Proposed workshop duration (half a day up to two days is possible).
+ If the workshop has met previously, please include the conference
affiliation for the previous meeting. If the workshop is new,
please indicate so.
CICM will take care of copying and distributing informal printed
proceedings for workshops that would like this service, as well as
permanently archived open access online proceedings with CEUR-WS.org.
All proposals should be sent via email to
<a shape="rect" href="mailto:cicm-organizers@cs.bham.ac.uk?Subject=Re%3A%20CICM%202015%3A%20Call%20for%20Workshops&In-Reply-To=%3C20141202181514.271922430307%40gigondas.local%3E&References=%3C20141202181514.271922430307%40gigondas.local%3E">cicm-organizers@cs.bham.ac.uk</a>
for consideration by the CICM 2015 organizers:
Local Organization Chairs: Bruce Miller (NIST)
Abdou Youssef (GWU, USA)
General Program Chair: Manfred Kerber (U. Birmingham, UK)
Calculemus Track Chair: Jacques Carette (McMaster U., Canada)
DML Track Chair: Volker Sorge (U. Birmingham, UK)
MKM Track Chair: Cezary Kaliszyk (U. Innsbruck, Austria)
System & Data Chair: Florian Rabe (JUB, Germany)
Workshop Chair: Serge Autexier (DFKI, Germany)
Important dates:
Deadline for proposal submissions: January 23, 2015
Acceptance/rejection notification: February 4, 2015
Workshop dates: July 13-17, 2015
----------------------------------------------------------------------
</pre>
</div>Serge Autexierserge.autexier@dfki.dehttp://lists.w3.org/Archives/Public/www-math/Seeking: Canonicalizer for presentation MathMLmid:547D2B6E.2040902@jacobs-university.de2014-12-02T03:01:02+00:00<div>
<pre id="body">
<a shape="rect" accesskey="j" id="start0" name="start0"></a>Dear Math working group,
dear MathML enthusiasts,
I am seeking a tool for canonicalization of presentation MathML, that is
as true as possible to the MathML specification, as well as the "intent"
behind the specification.
In other words, I am wondering if there is a piece of software (e.g. an
XSLT stylesheet) that is endorsed either by the W3C MathML group itself,
or at least "looks reasonable" to individual members.
I have seen a number of open source projects online that tackle the
problem, but I lack an overview of their maturity and compliance to the
spec. Hence, I am asking for advice.
To state the obvious, the ideal tool would map any two presentation
trees that (are intended to) render the same, to the same canonical
expression.
Thanks for any leads,
Deyan
</pre>
</div>Deyan Ginevd.ginev@jacobs-university.dehttp://lists.w3.org/Archives/Public/www-math/Things you can do with <b>MathML</b> | Joseph Rextag:josephrex.me,2014-11-28:/things-you-can-do-with-mathml//2014-11-28T05:05:42+00:00For a while, I've been enjoying the awesomeness of <em>mathML</em>. I've not had specific use cases but just playing around with it gives me fun. Sometimes I idly just write equations that should be on a paper in my local web pages.Joseph Rexhttp://www.google.com/search?hl=en&q=mathml&ie=utf-8&tbm=blgOpen Source Insider: Berners-Lee: new HTML5 'open web' milestoneshttp://ct.moreover.com/?a=19656106885&p=1cb&v=1&x=i1xWHoJmBSN4qS5EiMdnGQ2014-11-24T20:22:00+00:00<table width="100%"><tr><td width="99%" valign="top">
Computer Weekly - <b>Found Nov. 24, 2014</b><br />• programmatic access to a resolution-dependent bitmap canvas • native support for scalable vector graphics (SVG) and math (MathML);<br />
</td><td width="1%" valign="top">
</td></tr></table>Ask.com News Search for "mathml"http://www.ask.com/news?q=mathmlHTML5 is a W3C Recommendationhttp://www.w3.org/blog/news/?p=41672014-11-20T16:04:54+00:00<p><a href="http://www.w3.org/TR/html5/" class="imageLink"><img src="http://www.w3.org/html/logo/downloads/HTML5_Logo_128.png" width="128" height="128" alt="HTML5" /></a> The <a href="http://www.w3.org/html/wg/">HTML Working Group</a> today published <a href="http://www.w3.org/TR/2014/REC-html5-20141028/">HTML5</a> as W3C Recommendation. This specification defines the fifth major revision of the Hypertext Markup Language (HTML), the format used to build Web pages and applications, and the cornerstone of the Open Web Platform.</p>
<p>“<em>Today we think nothing of watching video and audio natively in the browser, and nothing of running a browser on a phone,</em>” said <strong>Tim Berners-Lee, W3C Director</strong>. “<em>We expect to be able to share photos, shop, read the news, and look up information anywhere, on any device. Though they remain invisible to most users, HTML5 and the Open Web Platform are driving these growing user expectations.</em>”</p>
<p>HTML5 brings to the Web video and audio tracks without needing plugins; programmatic access to a resolution-dependent bitmap canvas, which is useful for rendering graphs, game graphics, or other visual images on the fly; native support for scalable vector graphics (SVG) and math (MathML); annotations important for East Asian typography (Ruby); features to enable accessibility of rich applications; and much more.</p>
<p>The <a href="http://www.w3.org/html/wg/wiki/Testing">HTML5 test suite</a>, which
includes over 100,000 tests and continues to grow, is strengthening browser interoperability. Learn more about the <a href="http://testthewebforward.org/">Test the Web Forward</a> community effort.</p>
<p>With today’s publication of the Recommendation, software implementers benefit from <a href="http://www.w3.org/2004/01/pp-impl/40318/showCommitments">Royalty-Free licensing commitments</a> from over sixty companies under W3C’s Patent Policy. Enabling implementers to use Web technology without payment of royalties is critical to making the Web a platform for innovation.</p>
<p>Read the <a href="https://www.w3.org/2014/10/html5-rec.html.en">Press Release</a>, <a href="https://www.w3.org/2014/10/html5-rec.html.en#testimonials">testimonials from W3C Members</a>, and
<a href="http://www.w3.org/2014/10/html5-rec.html.en#acks">acknowledgments</a>. For news on what’s next after HTML5, see <strong>W3C CEO Jeff Jaffe’s blog post</strong>: <a href="http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/">Application Foundations for the Open Web Platform</a>. We also invite you to check out our video <a href="http://vimeo.com/w3c/buildstandards">Web standards for the future</a>.</p>Ian Jacobshttp://www.w3.org/blog/newsDisplay MathML with Html5-Javascript solutiontag:blogger.com,1999:blog-8964504625475983740.post-13717483255713493032014-11-06T09:31:00+00:00Hi,<br /><br /> A new solution to display MathML on web using only HTML 5 / Javascript technologies is available for download:<a href="http://www.fmath.info/java/download.jsp"> http://www.fmath.info/java/download.jsp</a><br /><br />A page with examples for all tags and how to use:<br /><a href="http://www.fmath.info/formula/js/how_to_use.jsp">http://www.fmath.info/formula/js/how_to_use.jsp</a><br /><br />The list of tags implemented from MathML is here:<br /><a href="http://www.fmath.info/whatIsImplemented.jsp">http://www.fmath.info/whatIsImplemented.jsp</a><br /><br />An example for mroot and msqrt tags (ltr and rtl implementation):<br /><br /><img src="http://www.fmath.info/java/renderer/images/800cd31c0228eec5e21356e335701e11.png" width="100%" /><br /><br />regards<br />Ionel Alexandru<img src="http://feeds.feedburner.com/~r/MathmlForAdobeFlashPlayer/~4/xQy3mTlUSrs" height="1" width="1" alt="" />Ionel Alexandrunoreply@blogger.comhttp://mathmlflash.blogspot.com/MathFlow in Action @ tekom Stuttgarthttp://news.dessci.com/1841 at http://news.dessci.com2014-11-06T04:10:35+00:00<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>We will be showing our MathML editing tools at the Tekom conference in Stuttgart, Germany November 11-13, 2014. If you're a technical writer, documentation manager, content strategist, consultant or systems integrator you should know about MathFlow, especially if you're involved in structured XML content. We have tools that work with Oxygen, FrameMaker, Flare, XMetaL, Arbortext and Codex, to name a few. If you or any of your colleagues back at the office are working with any math content at all, visit us in Hall 1, stand 1/C02 to find out about MathFlow.</p>
<p>Don't miss Autumn Cuellar's presentation: <strong><em>What you need to know about the Maths Stack: MathML, MathJax, HTML5, and EPUB 3</em></strong>, on Thursday Nov 13, 08:45 - 09:30, room C7.3 OG.</p>
<p>We hope to see you there!</p>
<p>If you're not going to be able to make it, check out our <a class="external-link" href="http://www.dessci.com/en/company/events.htm" rel="nofollow">event schedule</a> to see the other shows we will be attending. We'll also be posting Autumn's slides on the events page after the conference.</p>
</div></div></div><div class="field field-name-field-blog-category field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Topics in this post: </div><div class="field-items"><div class="field-item even"><a href="http://news.dessci.com/taxonomy/term/81">Events</a></div><div class="field-item odd"><a href="http://news.dessci.com/taxonomy/term/151">EPUB</a></div><div class="field-item even"><a href="http://news.dessci.com/taxonomy/term/161">HTML5</a></div><div class="field-item odd"><a href="http://news.dessci.com/taxonomy/term/141">MathML</a></div><div class="field-item even"><a href="http://news.dessci.com/taxonomy/term/111">MathFlow</a></div></div></div>Design Science Newshttp://news.dessci.com