Nabble - w3.org - www-math

Re: [Content.math-bridge.org] Synergize Notations DB & CD Links?

2009-12-17T03:24:05Z

Le 16-déc.-09 à 21:30, AJG Baeumel a écrit :
> Could we envisage a synergy between the notation census [http://wiki.math-bridge.org/display/ntns
> ]
> and the "links from CD pages"
> to see and gauge what has already been achieved and what still
> requires to be done?

Albert,

having discussed a bit longer with you, I agree we could have other
links than just "links from the OpenMath CDs to the notations".

Are all in these mailing-lists actually agreeing that searching by
graphically recognizing a notation is an important application?

thank in advance

paul

Synergize Notations DB & CD Links?

2009-12-16T12:30:48Z

To Whom It May Concern,

Could we envisage a synergy between the notation census [http://wiki.math-bridge.org/display/ntns]

and the "links from CD pages"

to see and gauge what has already been achieved and what still requires to be done?

AJG Bäumel ajgB@...

This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please notify the System Manager and thereafter delete the e-mail from your system. The System Manager may be contacted at postmaster@...

E-mail transmission is not secure and information can be intercepted, corrupted, lost, destroyed, delayed or incomplete. The sender does not accept any liability for errors or omissions arising as a result of e-mail transmission or interception. Please note that incoming e-mails are routinely scanned for the purpose of detecting offensive or inappropriate materials.

Re: Candidate Recommendation

2009-12-16T02:02:00Z

> Before MathML3 becomes a true Recommendation, I thought I should point
> out that the example given in 4.2.1.2 "Strict uses of <cn>" for the
> "hexdouble" datatype mentions that this holds 64 bits and 16 hexdigits
> (which is correct), but the example uses 8 hexdigits (which is incorrect).

Thanks for that, will fix.

> On the same subject, I was wondering why the "hexdouble" was created
A major aim of the revisons in Content MathML was to align with
OpenMath as MathML and OpenMath have always been "nearly aligned"
havig been developed by overlapping groups of people in overlapping time
frames.

http://www.openmath.org/standard/om20-2004-06-30/omstd20html-3.xml#sec_xml

OpenMath (probably) predates C99 design, as that part dates from some
time in the early 1990's.

Encoding al the forms in the string content without needing separate
markup at the xml level would have advantages and disadvantages. As you
say, it would be a bit simpler for languages that have exactly the same
syntax for double literals, but on the other hand it wuld be harder for
those that don't. If something validates using the (decimal) double form
then you can fairly safely drop it in as a numeric literal in most
languages, however the hex form requires some conversion in most
languages which do not have any native suppor for that. Openmath's
integer markup has this problem (<OMI> 16 </OMI> and <OMI> 0x10 </OMI>
being equivalent markup for 16) which means that you can not simply
drop an OpenMath XML integer into a conversion unless the target
language supports hex integers, without first inspecting the form of the
string literal. In an xml content it's often far more natural to drive a
conversion from the xml attribute structure rather than the syntax of
strings in the element content.

> but C99 does have a notation for NaNs, so there is a one-to-one mapping between
> C99 hex double notation and the binary form.

yes that's the main reason OpenMath has a hex form of doubces as well.

thanks again for your comments and we'll fix the incorrect example.

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: Candidate Recommendation

2009-12-16T01:30:13Z

Before MathML3 becomes a true Recommendation, I thought I should point
out that the example given in 4.2.1.2 "Strict uses of <cn>" for the
"hexdouble" datatype mentions that this holds 64 bits and 16 hexdigits
(which is correct), but the example uses 8 hexdigits (which is incorrect).

On the same subject, I was wondering why the "hexdouble" was created
(since the type did not exist in MathML2), and whether it would be more
economical to reference C99, and use its hexidecimal notation for
floats. A nice page descriping C99 hex doubles can be found at
<http://www.gnu.org/software/libc/manual/html_node/Parsing-of-Floats.html>.
Using this notation, a hex double could be encoded with the "double"
type, so the "hexdouble" type wouldn't be needed at all, and <cn> would
be easier to implement in C99 (with strtod), obviously. The reason the
"99" is important is that C89 did not have a notation for NaNs, but C99
does have a notation for NaNs, so there is a one-to-one mapping between
C99 hex double notation and the binary form.

Regards,

Andrew Robbins

Candidate Recommendation

2009-12-15T12:48:01Z

I'm pleased to be able to announce that the Candidate Recommendation
drafts of MathML3 and the MathML for CSS profile are available at

http://www.w3.org/TR/2009/CR-MathML3-20091215/

and

http://www.w3.org/TR/2009/CR-mathml-for-css-20091215/

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

Announcing the Notation Census

2009-12-12T06:02:51Z

I am happy to announce the launch of the Mathematical Notation Census,
a web-based recollection hosted by the Math-Bridge EU project.

The intent of this census is to collect the mathematical notations in
wide use around the world in a pictorial form with precise references
to existing works.

http://wiki.math-bridge.org/display/ntns

This project is a wiki intended to attract contributions from around
the world.
A notation is generally just an "observation": name a culture, provide
a picture, name the source.

You are welcome to register, comment, suggest further source of widely
used mathematical texts...

Paul Libbrecht

smime.p7s (2K) Download Attachment

Ambiguous description of annotation-xml/@encoding and @name

2009-12-07T02:29:26Z

Dear all,

I spotted some ambiguities and legacies in
http://www.w3.org/TR/MathML3/chapter5.html.

For MathML annotations it is said that the MIME types are
application/mathml-{content,presentation}+xml. However, all examples continue
to use the legacy syntax of MathML 2, such as encoding="MathML-Content".

Then, about the annotation keys, the descriptions of
"alternate-representation" and "contentequiv" overlap. For example, our
JOMDoc renderer (http://jomdoc.omdoc.org) outputs PMML annotated with, mostly,
OpenMath as parallel markup. Now, what annotation key should we use? Citing
myself from a mail to project-jomdoc@...
(http://lists.jacobs-university.de/mailman/listinfo/project-jomdoc):

> @cd/@name: points to a symbol, usually from the built-in "mathmlkeys" CD,
> that describes the semantic relation of the annotation to the formula it
> annotates. The two predefined values for @name are
> "alternate-representation" and "contentequiv". Now I'm not so sure which
> one to use; the MathML 3 spec is ambiguous here.
>
> "alternate-representation" includes the meaning "to provide an equivalent
> representation in another markup language", "not alter[ing] the meaning of
> the annotated expression". This is certainly the case for our annotations
> of PMML in OpenMath.
>
> "contentequiv" annotations are used "to disambiguate the meaning of a
> presentation MathML expression", for "clarifying its precise meaning".
> This is also what we are doing.

Do you have any recommendations?

Cheers, and thanks,

Christoph

--
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701

signature.asc (205 bytes) Download Attachment

Re: "XML Entity Definitions for Characters" Last Call Draft

2009-12-06T07:20:17Z

Martin,

thanks again for your comments on the last call draft of
XML Entity Definitions for Characters

The last call draft is at the URI:

http://www.w3.org/TR/2009/WD-xml-entity-names-20091117/

An Editors' draft showing the changes made in response to LC comments so
far is available at the URI:

http://www.w3.org/2003/entities/2007doc/Overview.html

I hope we have addressed all the points that you have raised. As you
will know, the W3C process requires that we log the resolution of every
last call comment, so we would appreciate it if you could confirm via an
email to www-math list whether all the points you have raised have been
addressed satisfactorily.

David

>
> Now for the comments themselves:
>
> Title: "XML Entity definitions for Characters" looks very ambigous. I
> think something like "XML Entity Definitions for Characters used by
> MathML" or so would help the general public a lot to understand the
> context and coverage of the document.

Although parts of this document were derived from the MathML2 spec
sources, this is explicitly _not_ just for MathML. It includes several
entity sets that are not included in the MathML DTD (isogrk1, isogrk2,
isogrk4, xhtml1-lat1, xhtml1-special, xhtml1-symbol, html5-uppercase) So
as well as being used for MathML it can be used for HTML (HTML5 uses
these definitions for example) and serves as an update for the (now
cancelled) ISO/IEC document 9573-13 defining the ISO entity sets. It
was for example cited in the docbook documentation for use with docbook
(now that docbook5 is RelaxNG defined and does not have its own set of
entity definitions). Thus it is important that the title does not
mention MathML as it is explicitly not just for MathML.

>
> abstract: "This document defines several sets of names which are
> assigned to Unicode characters. Each of these sets is also implemented
> as a file of XML entity declarations.":
> First, this says that the names are the main stuff, and the XML entities
> are just an implementation detail. This is a contradiction to the title,
> where XML entities are the main thing.

The statement you quote is factually true, however we have reworded
it to remove the implied relative importance of the different
aspects.

> Second, "sets of names which are assigned to Unicode characters" is
> unclear as to whether a set of names is assigned to a Unicode
> character, or something else. The same problem is present elsewhere
> (e.g. first sentence of the Introduction)

This has been reworded to clarify this.

> Third, all Unicode characters have official names (e.g. LATIN CAPITAL
> LETTER A for U+0041). These are a very important part of nailing down
> the identity of a character. It would be good if either the abstract or
> the Introduction or both would make clear that what you are dealing with
> are short mnemotic names that are different from the official Unicode names.

A comment pointing this out has been added to the introduction.

> Fourth, names being *assigned* to Unicode characters doesn't sound
> right. This may be a programmer's viewpoint, but what you are doing, in
> terms of an average programmig language, is to assign Unicode
> codepoints/characters to entity names, not the other way round. XML
> entities in this sense are not much different from variables in a
> programming language, so it would help a lot to keep things straight.
>

It is of course possible to view this mapping in either direction.
and in fact the mappings are implemented in both directions by the xml
entity files and the xslt character maps respectively. Although being a
many-many map these are not exact inverses. However as you say, it is
probably clearer to use the wording of assigning codepoints to names
rather than the other way round, and the document has been edited
accordingly wherever it used "assigned".

>
> Introduction:
> "The W3C Math Working Group has been invited to take over the
> maintenance and development of these sets by the original standards
> committee (ISO/IECJTC1 SC34).": It should say somewhere that this
> document is the result of this "taking over".
>
Well historically the document began before SC34 considered updating
9573-13 and a long time before they decided to cancel that project.
Informally they cancelled the project because this set was being more
actively maintained and although I was editing both documents I couldn't
keep to SC34 timescales as I couldn't get ahead of mathml3 and html5,
however we shouldn't speculate on the reasons behind the SC34
decision in the W3C REC track document.

>
> There should be a section on Notation, which explains things such as U+
> and leading slashes (is that TEX?).
>

It's pseudo TeX used (without explanation) in the original ISO standard.
The original ISO entity definitions only gave those descriptions (and no
unicode mappings) and the job really is to match those to unicode in the
most sane way possible subject to compatibility constraints. So I don't
want to change the entity description texts in any way as they are the
reference point for comparison to the ISO standards.

>
> Tables:
> http://www.w3.org/2003/entities/2007doc/bycodes.html:
> - Instead of U00009 and the like, please use the official U+0009
> notation, and do not use a hyphen for character sequences, as this may
> look like a character range.

We have revised the document to use U+ notation consistently. The U12345
ID form is just now used for internal linking, and for filenames, not
for referring to codepoints on the text or tables.

> - Use a <table> so that this displays decently even with
> non-proportional fonts (you can then eliminate the ugly commas). There
> are lots of cases where <table> is misused in Web pages, but this is
> clearly a case where it is "misunused" or "misnonused" or whatever one
> would call the absence of the use of a feature when such use is clearly
> warranted.
> - Use proper table headings
> - For character sequences, use e.g. "LESS-THAN SIGN with COMBINING LONG
> VERTICAL LINE OVERLAY" rather than "LESS-THAN SIGN with vertical line"
>

There were explicit requests from developers (when this table was in
MathML2) for an ascii file that could easily be tested against code,
the format that developed with the monospace layout but including some
hyperlinking is a compromise.

> http://www.w3.org/2003/entities/2007doc/byalpha.html:
> - Similar comments as for bycodes.html
> - I don't understand why this table contains the origins/collections,
> but bycodes.html doesn't.
> - I don't understand the lowercase stuff at the end of each line. It
> seems to be some kind of annotations, but in some cases is totally
> useless (e.g. [LATIN SMALL LETTER A WITH CIRCUMFLEX], latin capital
> letter A with circumflex)

The final field is the original ISO entity description. If it looks the
same as the unicode formal name than that is good, it isn't superfluous:
it is conformation that the entity has been paired with the right
unicode character. We note again that the original ISO entity definitions
_only_ gave those lower case descriptions not any unicode mapping.
However the order of the columns has now been changed so that this
entity description now comes after the entity name, with the Unicode
codepoint and formal name being the last two columns. Also information
has been added to the top of the file explaining what is in each
column.

> - This table puts the official Unicode names in "[" and "]", but
> bycodes.html doesn't. Why? There should be no such gratutious differences.

Accepted as an editorial improvement. Also the order of the columns has
been changed to put the entity description after the entity name rather
than after the Unicode formal name, and a paragraph describing the
column format has been added at the start of the page.

> http://www.w3.org/2003/entities/2007doc/000.html and similar:
> Please add a note to all the pages with lots of small glyphs that it may
> take time to load all the images to see all the glyphs. (one test run
> with Mozilla Firebug took 37 seconds on a broadband connection).

A suitable warning note has been added.

> Please use a stable, final location for all these GIFs. It's okay to
> have an occasional "301 Moved Permanently" for a page, but it
> essentially doubles the number of objects your page has to download from
> 256 to 512. Even the former isn't pretty, the later is definitely bad
> and totally unnecessary. (the redirects come from URIs of the form
> http://www.w3.org/2003/entities/glyphs/003/U003FF.png, the actual images
> seem to be at places such as
> http://www.w3.org/2003/entities/2007doc/glyphs/003/U003FF.png)

You happened to review the document while it was in transition, and the
redirects were put in place to keep everything working. Current builds
directly reference the new location of the png images, and the redirects
would only be used if someone has linked to the old locations.

> Codepoints U+0000 through U+0010 (with three exceptions) are shown as
> "Unicode or XML Non-Character". They are valid control characters in
> Unicode.

yes they are valid in unicode but not in XML 1.0 hence "Unicode or XML"
but see below.

> Strangely enough, there are also such cases (red background
> color) in the U+1D4xx and U+1D5xx 'blocks'. A codepoint such as U+1D53F
> is simply <reserved> in Unicode, the Unicode consortium could decide to
> allocate a character there in the future. This is no different at all
> from all the characters that you marked with a yellow background. The
> only codepoints that are actually non-characters in Unicode are cases
> such as U+FFFF and the like, but you don't have any of these. I
> therefore suggest that the red backgrounds in the U+1D4xx and U+1D5xx
> 'blocks' have to be turned to yellow, and the text for the red
> background should be changed to "Characters not representable in XML
> 1.0" or some such (most of them would be representable in XML 1.1).

All except 0000 would be representable in xml 1.1 as numeric references I think.
XML 1.1 came out after that text was written...
We don't want to mark the reserved "holes" in the 1Dxxx blocks the
same as completely unallocated codepoints.
The various cases are now separately distinguished (codepoint not usable
in xml 1,0, reserved codepoint in plane 1, unallocated codepoint) these
have been given different css classes and colours, and the key on each
table identifies the cases that occur on that page.

>
> For codepoints with a yellow background, the legend says "XML Character
> not currently described in Unicode". The term "XML Character" is really
> strange. XML uses Unicode, there are no "XML Characters".

"XML Characters" is intended to mean something matching the XML char
production, that is, a character usable as character data in XML,
which is a bit less than full unicode range as you know. However
the legend has been reworded as noted in the previous comment.

> The cells with
> yellow backgrounds represent unassigned (reserved) Unicode codepoints.
> So the best legend would be "reserved Unicode codepoint (no character
> currently assigned)" or something similar.

Looking at it from a unicode viewpoint it makes sense to say it's a
codepoint to which no character is currently assigned. But looking at it
from an xml viewpoint it _is_ a character (or more exactly it
corresponds to well formed character data matching the char production)
but unicode has not assigned any interpretation for that character.
As noted above the tables now distinguish more cases, separating out the
control characters (not usable directly in XML) from the reserved codepoints.

>
> Putting the "Next" link above the "Previous" link at the top and bottom
> of these tables seems counterintuitive, because the overall flow is from
> top to bottom.
>

The ordering was inconsistent, we have now consistently ordered these
links as suggested.

>
> For http://www.w3.org/2003/entities/2007doc/double-struck.html and similar:
>
> Why do some rows have a yellow background? There's no explanation, so
> the reader is left guessing.

They are highlighting the cases that are in the BMP not in the
(possibly?) expected runs in the 1Dxxx block. This was explained in a
note at the start of the section (in the overview document) however we
have added an additional footnote at the bottom of each affected page.

>
> Why do some of these characters not have any corresponding entity names
> at all?

Because, as stated explicitly in the introduction, this specification
doesn't define any new names, it only allocates unicode code points to
names previously thought up by ISO or the W3C.

>
>
> Section 3:
>
> Title: An "Unicode Character Block": As you can see from
> http://unicode.org/Public/UNIDATA/Blocks.txt, Unicode blocks are not of
> equal size of 256 characters, and are not all alligned on boundaries
> divisible by 256. But the reader can easily get such an impression. The
> title, or the text below it, should be changed to reflect this, unless
> (which would be more appropriate for the document (see next comment),
> but may be difficult in terms of production costs) actual Unicode blocks
> are used.
>

Yes in the table of contents all the block names that occur in the 256
square are listed, with "(continued)" added when the blocks run over.
The section title has been changed to use "Ranges" rather than "Blocks"
to avoid any impression that the 256 squares are Blocks.

> I don't understand why Arabic presentation forms are (as indicated by
> the yellow background) available in the STIX fonts, when basic Arabic
> isn't. Turning things around, would a font for Math or Science have to
> support these? The sentence "The following tables display Unicode ranges
> containing the characters that are most used in mathematics." at the
> start of section 3 seems to suggest so.

Given the list of blocks most used in science/mathematics (eg as listed
in unicode report 25) every 256-aligned range that covers those blocks
is listed, which means that some additional characters are shown in the
tables. The exact details of the Arabic support are somewhat in flux as
there are unicode proposals to add variant forms (in a similar manner to
the variants for latin and greek in 1d4xx and 1d5xx) and as for the
latin/greek cases there is some discussion as to whether existing
variant letters in the BMP should be reused.

>
> Turning things around: Are these tables for all the 256-character-sized,
> aligned parts that contain one or more of the characters for which
> entities have been defined in this document? If yes, please say so. If
> no, please say what the differences are.
>
As above; they are tables for all the 256-character-sized, aligned parts
that contain a math/science related block as listed in unicode tr 25.

>
> Section 5, first sentence: "there are some that use multiple character
> combinations": "multiple character combinations" is "multiple
> combinations of characters". However, characters are used in sequences,
> not in combinations. So "a sequence of multiple characters" or so would
> be better.
>

OK, change made.

>
>
> Editorial:
>
> - Please change 'definitions' to 'Definitions' it the title, or adopt
> any other W3C approved consistent casing convention. That such an
> inconsistency is 'traditional for this document' shouldn't be a reason
> to keep it.

agreed, d changed to D.

>
> Section 1, first sentence: "especially in scientific documents,
> especially in mathematics": Repetition; unclear about the relationship
> between the two clauses introduced by 'especially'.

agreed , this has been reworded.

> Section 1, second sentence: "has grown in part because its notation
> continually changes": I suggest changing "changes" to "changed" to align
> the tenses.
>

The tense of "changes" is intentional here. The evolution is still
in progress.

> Section 1, first paragarph: "It is difficult to write science fluently"
> -> "It is difficult to write scientific texts fluently"; same later for
> "read science".

This has been reworded.

>
> Section 3, first sentence: "Certain characters are of of particular
> relevance": "of of" -> "of"

The spurious "of" has been deleted.

>
> Section 5, first sentence: "character, however" -> "character. However"
> or "character, but" (however starts a new sentence)
>
I think "however" is being used as a conjunction there rather than start a
new sentence, however the phrase has been reworded.

Thanks again for the comments,

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

[Entities-last-call] - htmlmath entities collection

2009-12-03T05:08:19Z

This is a last call comment for the public record, noting an addition
made to the editor's draft of the XML Entity Definitions for Characters
specification. The change has already been made to the Editors' draft so
will be assumed resolved, however if anyone would like to comment on
this addition, please do reply to this message (on www-math list).

David

The entities last call draft

http://www.w3.org/TR/2009/WD-xml-entity-names-20091117/

includes a combined entity file w3centities-f that defines all the
entities defined in the specification.

As noted in a thread a while ago on the public-html list

http://lists.w3.org/Archives/Public/public-html/2009Nov/0305.html

for some uses it would be more useful to have a combined entity set just
including those sets used in mathml and html and omitting the other ISO
entity sets that are not typically used in a web context. This would
correspond closely with an updated version of the entity file that
firefox uses for mathml documents for example.

In the Editors' draft

http://www.w3.org/2003/entities/2007doc/Overview.html#sets

I've now added two files htmlmathml.ent (which references each of the
entity sets used by mathml or html) and htmlmathml-f.ent which directly
contains each definition, sorted into alphabetic order, with duplicates
removed.

http://www.w3.org/2003/entities/2007/htmlmathml.ent
http://www.w3.org/2003/entities/2007/htmlmathml-f.ent

there are no changes to any of the defined entity definitions resulting
from this addition.

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

CfP: Third International Congress on Mathematical Software

2009-11-30T13:52:26Z

The First Call for Papers of
The Third International Congress on Mathematical Software
[ ICMS'2010 --- developers meeting ]

(November 30, 2009)

Dates: September 13 to 17 (Monday to Friday), 2010
Place: Department of Mathematics, Kobe University, Kobe, Japan
Webpage: http://www.mathsoftware.org/

OVERVIEW

This congress is the third in the series, where the first meeting was
held in
Beijing in 2002 and the previous one in Castro Urdiales, SPAIN in
2006; see
http://www.icms2006.unican.es/ . The first two meetings were satellite
events
to ICM (International Congress of Mathematicians). We will have a
presentation
booth at ICM 2010 in India.

We will welcome developers of mathematical software systems as well as
researchers in algorithms and mathematicians who are interested in the
development of mathematical software and systems. This is an almost
unique
chance to meet people in different disciplines in mathematics and
computer
science and exchange ideas on developments on mathematical software and
systems. While the main audience of this meeting is assumed to be
developers of
mathematical software and software systems, we welcome the
participation of
mathematicians and scientists who are interested in using mathematical
software
for their research.

The proceedings of the congress is planned and all reviewed papers and
short
communications will be published as Springer Lecture Notes in Computer
Science.
(The proceedings of ICMS 2006 was published as LNCS Volume 4151.)

AIM AND SCOPE

Mathematics has a wide variety of branches. Despite this, we in the
International Congress on Mathematical Software believe that
mathematics is
fundamentally just one thing. Algebra, geometry and analysis are
examples of
separate specialities within mathematics, and of course we consider
each of
them valuable and hence study them. But we take the view that any
branch of
mathematics can borrow freely from these specialities. It is often
worthwhile
delving into them for ideas that might lead to fundamental new
discoveries.
The same can be said of mathematical software systems: the study of
mathematical software is a coherent whole. We believe that the
appearance of
mathematical software is a fundamentally new event in mathematics of
increasing
importance. Mathematical software systems are used to construct
examples, to
prove theorems, and to find new mathematical phenomena. Conversely,
mathematical
research often motivates developments of new algorithms and new
systems. Beyond
mathematics, mathematical software systems are becoming indispensable
tools in
many branches of science and technology. The development of mathematical
software systems relies on the cooperation of mathematicians, algorithm
designers, programmers, and the feedback from users. The main audience
of this
congress is the community of mathematical software developers and
programming
mathematicians, but we also intend to provide an opportunity to
discuss these
topics with mathematicians and users from application areas. Topics
include but
are not limited to:
1. Design and implementation of mathematical software
2. Software engineering problems for mathematical software.
3. Mathematics and media including user interfaces and integration of
documents
and software systems.
4. Mathematics related to mathematical software (experiments,
algorithms).
5. Scientific and high performance computing.
6. Applications of mathematical software.

CONFIRMED PLENARY SPEAKERS

* Thomas Hales, University of Pittsburgh, USA
* Masakazu Kojima, Tokyo Institute of Technology, Japan
* Kurt Mehlhorn, Max Planck Institute for Informatics, Saarbruecken,
Germany
* William Stein, University of Washington, USA

LIST OF SESSIONS

This congress is comprised of some sessions devoted to different
Mathematical
Software issues as well as a general track. As a rule, the general
track will
/u/fukuda/Pictures/iPhoto Library/Modified/2009/GretchenParlato/
DSC_0039.JPGconsists of all accepted papers/presentations which do not
belong to any of the
sessions listed below. So far, the following sessions have been
confirmed:
____________________________________________________________________________
Title: Computation of special functions
Organizer: Annie Cuyt
____________________________________________________________________________
Title: Computer tools for mathematical editing and scientific
visualization
Organizer: Andres Iglesias, Setsuo Takato
____________________________________________________________________________
Title: Exact numeric computation for algebraic and geometric computation
Organizer: Chee Yap, Michael Sagraloff, Monique Teillaud
____________________________________________________________________________
Title: Methods in computational group theory
Organizer: Bettina Eick, Steve Linton
____________________________________________________________________________
Title: Formal proof
Organizer: John Harrison, Freek Wiedijk
____________________________________________________________________________
Title: Geometry and visualization
Organizer: Konrad Polthier
____________________________________________________________________________
Title: Groebner bases and industrial applications
Organizer: Hidefumi Ohsugi
____________________________________________________________________________
Title: Number theoretical software
Organizer: Shigenori Uchiyama, Ken Nakamula, Michael Pohst
____________________________________________________________________________
Title: Software for optimization and polyhedral computation
Organizer: Achill Schuermann, Komei Fukuda, Michael Joswig
____________________________________________________________________________
Title: Computer algebra and reliable computing
Organizer: Joris van den Hoeven
____________________________________________________________________________
Title: Arts and mathematics
Organizer: Komei Fukuda, Vera Rosta
____________________________________________________________________________
* If you have suggestions for new sessions, please contact one of
the program committee members or the general chair.

DATES

* March 8, 2010: Submission of papers/short communications begins
* May 10, 2010: Submission due of papers/short communications
* June 11, 2010: Notification of acceptance
* June 25, 2010: Submission due of camera-ready papers and short
communications
* July 15, 2010: Early registration due

CHAIRS
Nobuki Takayama (Kobe), general chair
Komei Fukuda (ETH), program committee cochair
Joris Van der Hoeven (Paris 11), program committee cochair
Michael Joswig (TU Darmstadt), program committee cochair
Masayuki Noro (Kobe), local organization chair

PROGRAM COMMITTEE

* Annie Cuyt, http://cant.ua.ac.be/people/annie.cuyt
* Komei Fukuda, http://www.ifor.math.ethz.ch/~fukuda/
* Tatsuyoshi Hamada, http://holst.sm.fukuoka-u.ac.jp/~hamada/
* John Harrison, http://www.cl.cam.ac.uk/~jrh13/
* Joris van der Hoeven, http://www.texmacs.org/joris/main/joris.html
* Andres Iglesias, http://personales.unican.es/iglesias/
* Michael Joswig, http://www.mathematik.tu-darmstadt.de/~joswig/
* Paul Libbrecht, http://www.activemath.org/~paul/
* Hidefumi Ohsugi, http://www.rkmath.rikkyo.ac.jp/~ohsugi/
* Michael Pohst, http://www.math.tu-berlin.de/~pohst/
* Konrad Polthier, http://page.mi.fu-berlin.de/polthier/
* Shigenori Uchiyama <uchiyama-shigenori AT tmu.ac.jp>
* Freek Wiedijk, http://www.cs.ru.nl/~freek/
* Chee Yap, http://www.cs.nyu.edu/yap/

ADVISORY PROGRAM COMMITTEE

* Henk Barendregt, http://www.cs.ru.nl/~henk/
* Arjeh Cohen, http://www.win.tue.nl/~amc/
* Dan Grayson, http://www.math.uiuc.edu/~dan/
* Gert-Martin Greuel, http://www.mathematik.uni-kl.de/~greuel/en/
* Jean Lasserre, http://homepages.laas.fr/~lasserre/
* Bernard Mourrain, http://www-sop.inria.fr/members/Bernard.Mourrain/
* Ken Nakamula, http://tnt.math.metro-u.ac.jp/~nakamula/
* Bernd Sturmfels, http://math.berkeley.edu/~bernd/
* Jan Verschelde, http://www.math.uic.edu/~jan/
* Dongming Wang, http://www-salsa.lip6.fr/~wang/

PAPER SUBMISSION

We will accept original research papers (max 12 pages) or short
communications
(max 3 pages). Short communications are expected to be research
announcements
or extended abstracts of original research. All submitted documents
will be
reviewed, and those accepted will be published as Springer Lecture
Notes in
Computer Science; see the LNCS Home Page www.springer.com/lncs .

This congress is comprised of some sessions devoted to different
Mathematical
Software issues as well as a general track. When submitting a paper,
please
check if it fits into the aims and scope of any session (see above for
the
current list of sessions). If so, submit your manuscript to a
submission server
by following the instructions in the webpage http://www.mathsoftware.org/
.
The submission server is expected to accept submissions from March 8,
2010.

CONTACT INFORMATION
For any general questions regarding this congress, please contact:
(For questions on a particular session, please contact session
organizers.)

General Chair
Prof. Nobuki Takayama
Department of Mathematics
Kobe University
Rokko, Kobe 657-8501, Japan
E-mail: takayama AT math.kobe-u.ac.jp
Phone: +81-78-803-5604

PC Cochair
Prof. Komei Fukuda
Institute for Operations Research
ETH Zentrum, CH-8092 Zurich, Switzerland
http://www.ifor.math.ethz.ch/staff/fukuda/
E-mail:fukuda AT ifor.math.ethz.ch
Phone: +41-44-632-4023

Local Organization Chair
Prof. Masayuki Noro
Department of Mathematics
Kobe University
Rokko, Kobe 657-8501, Japan
E-mail: noro AT math.kobe-u.ac.jp
Phone: +81-78-803-5624

Re: Underscript-overscript Pair (munderover) is not working properly on Firefox

2009-11-30T00:31:26Z

Here you use inline formula, so the default displaystyle value is
"false" to save vertical space. I think you simply need to put your
<munderover/> in a <mstyle displaystyle="true"></mstyle>.

HTH

> Copy the following text and save as an xhtml or xht file. When I open
> this file in Firefox 3.5.5 on my desktop (Windows XP Pro SP2), it
> displays the upper and lower limits as sub and sup. I want it to
> display these limits as under and over the summation symbol. Please help:
>
> ////////////////File begins///////////////////////////
> <?xml version="1.0"?>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN"
> "http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd" [
> <!ENTITY mathml "http://www.w3.org/1998/Math/MathML">
> ]>
> <html xmlns="http://www.w3.org/1999/xhtml">
> <head>
> <title>Minimum Document with MathML</title>
> </head>
> <body>
> <p>
> Accept all valid XHTML and MathML, including therefore
> <a href="http://www.mozilla.org/">links</a
> <http://www.mozilla.org/%22%3Elinks%3C/a>>
> and math fractions
> <math xmlns="&mathml;">
> <munderover>
> <mo> ∑ </mo>
> <mn> 0 </mn>
> <mi> 5 </mi>
> </munderover>
> </math>
> </p>
> </body>
> </html>
> ////////////////File Ends///////////////////////////
> Thank you,
> Saf
>
>

Underscript-overscript Pair (munderover) is not working properly on Firefox

2009-11-29T20:03:05Z

Copy the following text and save as an xhtml or xht file. When I open this file in Firefox 3.5.5 on my desktop (Windows XP Pro SP2), it displays the upper and lower limits as sub and sup. I want it to display these limits as under and over the summation symbol. Please help:

////////////////File begins///////////////////////////
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN"
               "http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd" [
<!ENTITY mathml "http://www.w3.org/1998/Math/MathML">
]>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>Minimum Document with MathML</title>
</head>
<body>
    <p>
      Accept all valid XHTML and MathML, including therefore
      <a href="http://www.mozilla.org/">links</a>
      and math fractions
      <math xmlns="&mathml;">
        <munderover>
       <mo> ∑ </mo>
       <mn> 0 </mn>
       <mi> 5 </mi>
</munderover>

</math>
</p>
</body>
</html>
////////////////File Ends///////////////////////////

Thank you,

Saf

Re: please comment on media-type registrations for MathML

2009-11-24T08:02:56Z

Dear media-types-expert,
Dear Björn,

> Forwarded-from : member-math@...
> From : "Robert Miner" <robertm@...>
> Date : 24 novembre 2009 03:43:50 GMT+01:00
> To : <member-math@...>
> Archived-At: <http://www.w3.org/mid/D1EFB337111B674B8F1BE155B01C6DD6034CCA68@...
> >
>
> Dear Björn,
>
> I am writing in response to your comments on the media-type
> registrations for MathML given in Appendix B of the Last Call draft of
> the MathML 3 Specification. Your original comments are recorded at
> http://www.alvestrand.no/pipermail/ietf-types/2009-October/
> 002268.html.
>
> We have modified Appendix B, and believe we have addressed the issues
> you noted. The changes are explained below, and you can see the draft
> changes in an editor's draft of the spec located at
>
> http://monet.nag.co.uk/~dpc/draft-spec/appendixb.html
>
> Since we need to record the resolution of all Last Call comments,
> could we ask you to let us know whether you accept these changes as
> addressing your comments? Thanks in advance.
>
> The specific actions taken are:
>
> > The first problem I have with this is that there is no word on what
> > exactly the various types are for, like if there are any
> restrictions
> > on what should be in a mathml-content+xml vs a mathml-presentation
> +xml
> > document, or if the types can be used with MathML 2.0.
>
> A new introductory section entitled "Selection of Media Types for
> MathML Instances" was added to specifically address this issue. The
> related text in section 6.2.3 of the spec is essentially summary in
> nature, and was therefore left unchanged. It already referred to
> appendix B for detailed information on the usage of the media types,
> and that information is now given.
>
> The section carefully defines the presentation and content MathML
> vocabularies, and gives a clear rule for determining what media type
> should be used for a given MathML instance based on the contents of
> that instance.
>
> The section also contains some explanation and examples to motivate
> the usage of the three MathML media types. The section ends by
> addressing use of the media types with earlier versions of MathML
>
> > As per RFC 3023, the charset definition and encoding considerations
> > should be referenced as follows, which the proposals fails to do:
> >
> > Registrations for new XML-based media types under top-level types
> > other than "text" SHOULD, in specifying the charset parameter and
> > encoding considerations, define them as: "Same as [charset
> parameter
> > / encoding considerations] of application/xml as specified in RFC
> > 3023."
>
> These sections have been edited to match the proper format.
>
> > The security considerations are missing (in fact the specification
> > as a whole does not have a security considerations section either).
>
> Security considerations have been added. We have listed both the
> generic issues common to similar XML languages, and two issues
> specific to MathML: the possible presence of executable code in
> semantic annotations, and the (possibly inadvertant) denial of service
> risks arising in computational contexts from trying to solve
> unsolvable problems.
>
> > I believe the text you have under "interoperability considerations"
> > is misplaced there in all three cases.
>
> This text has been completely rewritten. Again, there are some
> generic considerations common to similar XML languages, as well as
> several MathML specific issues. In particular, lack of versioning
> information in MathML instances introduces a backward compatibility
> concern, and the result of evaluating MathML expressions is not
> guaranteed to be the same in different computational systems.
>
> > I note that under "Applications that use this media type" you have
> > "(todo)". Going to Last Call with "todo" markers left is not a good
> > practise. I note that the purpose of this field is to give a general
> > idea of what kind of applications use it, not to list individual
> > software products.
>
> Thank you for the clarification on the purpose. We have filled out
> the section appropriately.
>
> > Under "Person & email address to contact for further information"
> > the proposal fails to properly separate name and email address, use
> > something like "Name <address>" instead. I do not think having a
> > generic W3C / W3C Webmaster combination there is a good practise
>
> Following other media type registrations under the BCP13 process, we
> have changed this to list Paul as the person, with the Math WG group
> mailing list for the address, followed by a pointer to the public W3C
> Math web site for additional information.
>
> --Robert
>
>

Re: [MathML3-last-call] comments from HTML WG

2009-11-22T18:20:52Z

Shelley, thanks for the speedy feedback, it's really appreciated

>....... Note that section 6.4.2 has a typo, ffer rather
> than offer.

Hmm I think I'm to blame there, sorry:-) Thanks for catching that.

fixed in sources: (and the generated draft updated)

$ cvs commit -m "ffer" world-interactions.xml
Checking in world-interactions.xml;
/w3ccvs/WWW/Math/Group/spec/xml/world-interactions.xml,v <-- world-interactions.xml
new revision: 1.68; previous revision: 1.67
done

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: [MathML3-last-call] comments from HTML WG

2009-11-22T18:02:56Z

Thank you very much, Shelley, for your answers and for pitching
in to get comments to the Math WG in the first place.

We'll fix the typo
ffer => offer

Best wishes,

Patrick

On Nov 22, 2009, at 8:51 PM, Shelley Powers wrote:

> David, Math WG, thanks for the response.
>
> Embedded in the message are my responses to your changes. Note others
> of the HTML WG may have additional responses, though we all realize
> that you must have all responses in this week.
>
.....

Re: [MathML3-last-call] comments from HTML WG

2009-11-22T17:51:18Z

David, Math WG, thanks for the response.

Embedded in the message are my responses to your changes. Note others
of the HTML WG may have additional responses, though we all realize
that you must have all responses in this week.

>
> As noted below we have fixed the definite mistakes that you reported
> and have tried to add clarifying text to address the other issues you
> raised. The results can be seen at the editors' draft
>
>
> http://monet.nag.co.uk/~dpc/draft-spec/chapter2.html#fund.attval
>
>
> >
> > Related to the addition of the new href attribute[1]:
> >
> > 1. The attribute href has been added for use with several MathML
> > elements, rather than using xlink:href, from MathML 2.0. However, the
> > document states that because of compound document requirements,
> > xlink:href can still be used. This could cause confusion when viewing
> > the documentation for MathML as foreign object in HTML5. In the HTML5
> > specification, if the href attribute is associated with the XLink
> > namespace, it must be given as xlink:href in the document.
> >
>
>
> Foreign namespaced attributes are allowed in MathML3, as they are in
> earlier versions of MathML, so syntactically xlink attributes are allowed
> by general principles, but the MathML3 spec is quite explict that href is the
> preferred form for use as a hyperlink. We have adjusted the text in
> section 6 to make this clearer and to give advice to existing
> mathml2+xlink applications.

Unless anyone has any other questions or comments, you've addressed
our concerns.

>
> RCS file: /w3ccvs/WWW/Math/Group/spec/xml/world-interactions.xml,v
>
> revision 1.59
> date: 2009/11/18 04:08:00; author: rminer; state: Exp; lines: +19 -14
> linking rewrites
>
>
>
> > The MathML href attribute is now, by default, associated with the
> > MathML namespace. But this isn't specifically stated in the document,
>
> Like all unprefixed attributes it is in no namespace. It is not
> associated with the MathML namespace, thus we do not know what
> statement you expected to see here, we are assuming no change is
> required to the document. If you feel some clarification is needed,
> please respond further on this point.
>

No, this is fine.

>
>
> > and someone reading both may become confused, and assume they have to
> > use xlink:href with MathML embedded in HTML5.
>
> xlink:href was only mentioned in passing in one or two places,
> discussing differences with MathML2 so we were not sure why you thought
> someone would have to use xlink, but as noted above we have
> adjusted the wording in section 6.4.2 Linking to try to make this
> clearer.
>

Yes, the language is fine.

> > The document may want to
> > demonstrate how href can be used with embedded MathML in the document
> > section detailing MathML embedded in HTML.
>
> This section has been rewritten, href should not really need an example,
> it takes a URI (LEIRI) as value and is used exctly the same way as a
> href in html for example.
>

Unless others express a new comment or concern, you've addressed our concerns.

> >
> > 2. Is the plan to drop support for xlink:href in MathML UAs at some
> > point? If not, we're curious as to why the Math WG introduced the new
> > attribute?
>
> xlink was not widely supported amongst mathml2 UAs in any case, for
> example as far as we can tell it doesn't work in any current browser
> implementation of mathml (although it has worked in firefox)
>
> xlink is a separate specification which user agents may or may not wish
> to implement, the MathML spec can not say what other specifications
> should be implemented by applications. We have revised the text in 6.4.2
> to give advice on what an application supporting both xlink and native
> mathml linking should do. The issue here though is just the same as in
> xhtml, if an application supports xlink and xhtml there is the
> possibility of having both href and xlink:href on the same element.
>
>
>
> >
> > 3. If the UA supports both, what should happen when both are specified
> > on one element?
>
>
> Formally this is out of scope for MathML, however we have given some
> advice that href be preferred in the revised linking section.
>
>

Again, unless someone provides a new comment or concern, this
addresses our concerns.

> >
> > 4. We're also curious as to why the new href attribute takes a URI
> > rather than IRI?
>
> Thanks for catching this, we will add some clarifying text.
>
> Most XML related specifications (including XML itself and XSD) as well
> as MathML use "URI" (or "URL" in older specs such as XML or MathML1) to
> mean essentially what is now known as an IRI (or differing in some edge
> cases, a LEIRI). The MathML attributes that are described as type URI
> are actually XSD schema typed as xs:anyURI which means that they have a
> lexical space of any string and the system is supposed to %-encode any
> characters not allowed in URI. Effectively this means that they take an
> IRI. We have added wording to the table of common attribute types in
> 2.1.5 where this attribute type is introduced.
>
> http://www.w3.org/TR/MathML3/chapter2.html#fund.attval
>
> Adding reference for URI to both the current IRI RFC,
>
> http://www.ietf.org/rfc/rfc3987.txt
>
> and its proposed update
>
> http://tools.ietf.org/html/draft-duerst-iri-bis-07
>
>
>
>
> $ cvs commit -m IRI fundamentals.xml references.xml
> Checking in fundamentals.xml;
> /w3ccvs/WWW/Math/Group/spec/xml/fundamentals.xml,v <-- fundamentals.xml
> new revision: 1.127; previous revision: 1.126
> done
> Checking in references.xml;
> /w3ccvs/WWW/Math/Group/spec/xml/references.xml,v <-- references.xml
> new revision: 1.90; previous revision: 1.89
> done
>
>
>
>

Thanks, unless there are new comments or concerns, this should address
our concerns.

> >
> >
> > Related to the Chapter 6.4, Combining MathML and Other Formats, and
> > specific to 6.4.1, Mixing MathML and HTML:
> >
> > 5. The specification includes a section discussing MathML and HTML.
> > However, the section only references MathML in XHTML. With HTML5,
> > MathML can be used in HTML, and there are additional constraints on
> > using MathML in HTML, including the fact that the outer math element
> > is specified without a prefix (such as m:math, as shown in the
> > example), though the use of a namespace and prefix can work with
> > XHTML.
> >
> > There are other constraints associated with MathML in HTML. Could this
> > one section be split in two, with one section detailing MathML in
> > XHTML, and one in HTML?
> >
> > In particular, HTML allows unquoted attributes, and elements without
> > closing tags (if such are given in the list of allowed elements
> > without closing tags). These looser specifications also apply to
> > foreign
> > objects such as SVG and MathML (though user agents are encouraged to
> > provide an export facility providing properly formatted XML). However,
> > people can paste properly formatted XML into HTML, and it will be
> > supported.
>
>
> The existing MathML+HTML section in chapter 6 has been split into two,
> one for XHTML and one for non-xml syntaxes, specifically HTML5.
>
> Note however the MathML specification defines MathML as an XML
> application, if other specifications define mathml variants with
> different syntax then it is that specification that must specify
> the differences. (HTML5 effectively does that by specifying how
> the html-like syntax is parsed to an xml dom).
>
>
>
> $ cvs commit -m html5 references.xml world-interactions.xml
> Checking in references.xml;
> /w3ccvs/WWW/Math/Group/spec/xml/references.xml,v <-- references.xml
> new revision: 1.91; previous revision: 1.90
> done
> Checking in world-interactions.xml;
> /w3ccvs/WWW/Math/Group/spec/xml/world-interactions.xml,v <-- world-interactions.xml
> new revision: 1.62; previous revision: 1.61
> done
>
>
>
> >
> > Pasting MathML into HTML does lead to another issue: the use of
> > namespaced attributes. Namespaced attributes can be included in
> > MathML, but, currently, the validator does provide a warning for
> > namespaced attributes in SVG or MathML when embedded in HTML. The same
> > applies to properly formatted XML entities and attributes that might
> > be included within the MathML annotation-xml
> > element.
>
> The behaviour of namespaced attributes is entirely implementation
> defined, they are allowed but no particular behaviour is mandated, so if
> for example they were just ignored by HTML systems that would be
> conformant, doing more would be helpful to the user, but not mandated.
>
> >
> > In addition, there are also, currently, DOM namespace handling
> > differences associated with MathML pasted into HTML, as compared to
> > MathML pasted into XHTML.
> >
>
> The MathML3 spec does not discuss the DOM at all, so while this might be
> true it does not affect the MathML3 specification. If we decide later to
> update the MathML2 DOM to a separate MathML3 DOM specification, this
> might become an issue.
>
> > Both the DOM differences and the validator warnings, in addition to
> > the syntax differences, such as unquoted attribute values, might be
> > surprising and confusing to folks who expect properly formatted XML in
> > HTML.
> >
>
> As noted above, the MathML specification only defines the XML syntax.
> If other specifications introduce syntactic variants, then any issues
> must be addressed in those specifications. However as HTML is an
> important special case, a mention of unquoted attributes in html is given
> as an example in the new html-specific section in chapter 6.
>
>
> > 6. The section contains the following passage:
> >
> > "To fully integrate MathML into XHTML, it should be possible not only
> > to embed MathML in XHTML, as described in Section 6.2.1 Recognizing
> > MathML in XML, but also to embed XHTML in MathML. However, the problem
> > of supporting XHTML in MathML presents many difficulties. Therefore,
> > at present, the MathML specification does not allow XHTML elements
> > within a MathML expression, although this situation may be subject to
> > change in a future revision of MathML."
> >
> > What are the difficulties referenced in the document?
> >
> > In particular, the HTML5 parser supports HTML and SVG in <mi>, <mo>,
> > <mn>, <ms>, <mtext> and SVG in <annotation-xml>. XHTML and SVG in
> > MathML in these places works fine in Firefox and Opera today when
> > using application/xhtml+xml. We're curious as to why MathML doesn't
> > allow what is, at a minimum, expressible in text/html?
> >
>
> the quoted section has been rewritten as that section has been split in
> two, as noted above so that HTML and XHTML can be discussed separately.
>

Thanks for the split. Note that section 6.4.2 has a typo, ffer rather
than offer.

A reference back to HTML5 and a note for people to be aware of
differences sufficiently answers the concerns. Thanks for doing this.

> Also, please refer to the reply given to the I18n group on a similar question.
>
>
> http://lists.w3.org/Archives/Public/www-math/2009Nov/0010.html
>
> The normative schema for MathML needs to restrict to text in for the
> reasons given. XHTML+MathML, being defined by a schema could use a more
> open schema that allowed nested XHTML elements. MathML in HTML5, being
> defined by the prose text of the HTML5 parse rules is defined by that
> specification not by MathML.
>
> It would be entirely wrong for the normative MathML schema to say that
> (X)HTML elements are by default allowed inside mtext. MathML as used by
> computer algebra systems (for example) probably can not deal with
> structured text at all, and docbook+MathML or XSL-FO+MathML (for
> example) would typically be processed by systems that could handle
> embedded docbook (or XSL-FO) elements in mtext but not HTML. This is why
> it needs to be the decision of the person defining the compound document
> format (XHTML+MathML or HTML+MathML) whether to allow nested HTML inside
> mtext. Even in a purely HTML+MathML application it isn't always
> possible to support nested HTML elements and mandating it would make
> some highly used systems non compliant. In a component architecture such
> as used by IE, if a different component is being used to render the
> MathML, it can not (given current API) easily call back to the host
> browser to render nested instances of HTML.
>
>

Thanks for the clarification. I believe your response answers our concerns.

>
> >
> > Other, general comments:
> >
> > 7. In the element listing [2] you show an element labelled td, but the
> > link associated with it leads to a section describing an element
> > labeled mtd. Possible typo?
>
> Thanks for catching this.
>
> That list is automatically generated from the xmlspec markup and it is
> highlighting a typo in 3.5.4.2 Attributes where td was used for
> mtd.
>
>
> This has been fixed in our sources.
>
> $ cvs commit -m "td to mtd" presentation-markup.xml
> Checking in presentation-markup.xml;
> /w3ccvs/WWW/Math/Group/spec/xml/presentation-markup.xml,v <-- presentation-markup.xml
> new revision: 1.292; previous revision: 1.291
> done
>
>

Thanks for the fix.

>
> >
> > 8. In the section describing color[3] you reference color names from
> > HTML4. Is there a reason MathML doesn't use css3-color SVG color
> > keywords instead of HTML4 color keywords?
>
> Initially (MathML1) there was no css3-color or svg.
> We did look briefly at extending this list but it wasn't clear that this
> would be useful: it doesn't really add any new functionality (since hex
> colours are supported) and typically isn't currently supported by
> MathML2 systems. HTML5 has these extended color names but introduces
> them as
>
> "Some obsolete legacy attributes parse colors in a more
> complicated manner,"
>
> which doesn't really encourage these colours to be added as a new feature
> to other specs such as MathML3
>
>
> Adding the long list of X11/SVG colour names to MathML3 at this time
> would hurt interoperability with existing MathML systems that do not
> support them, and offers no real extra features (as the colours may be
> specified using the hex rgb syntax). Supporting the extended list imposes
> a non negligable implementation cost on any implementation that is not
> hosted in a CSS environment that already supports these colours.
>
>

I believe Philip Taylor may have had additional comments on this[1].
If he doesn't have any other concerns, this should be sufficient
response to our concerns.

> >
> > 9. The index lists two values, my:background and my:color, which are
> > also demonstrated in the section to which they're linked. These would
> > seem to be from demonstrations of bringing in color or background from
> > another namespace. Including them in the index could generate
> > confusion.
>
> The index (which is automatically generated) indexes the use of these
> attributes. Why do you think it confusing to index an example that is
> there? Perhaps you mean that the example is confusing, but if so could
> you give some indication of what in particular causes confusion or what
> could be changed to lessen the confusion.

I believe the concerns were that you used my:background and my:color
as a generic use of namespaced attributes. But by them showing up in
the index, they could lead people to believe they are formally defined
namespaced attributes, defined for some reason in the specification.

However, this isn't an error, more a comment, so no action is required
for this concern.

David, thanks again for your and the Math WG's response to these concerns.

>
> David Carlisle
> For the Math WG
>

Shelley

Re: [MathML3-last-call] mathvariant

2009-11-22T13:17:11Z

> I "don't have permission to access /~dpc/draft-spec/" on
> http://monet.nag.co.uk/

oops sorry please use

http://monet.nag.co.uk/~dpc/draft-spec/Overview.html

I'll put a redirect in so the directory works as well.
We've switched to the w3c default of Overview.html from
overview.html

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: [MathML3-last-call] mathvariant

2009-11-22T13:11:08Z

On Fri, 20 Nov 2009 11:51:21 -0700, Sam Dooley wrote:

> Resolved with improved wording for sections 3.2.2 and 7.5.
>
> /w3ccvs/WWW/Math/Group/spec/xml/character-set.xml,v <-- character-set.xml
> new revision: 1.106; previous revision: 1.105
> done

Thank you for comments and clarifications here, Sam.
I think they've helped me understand the situation.

Is there somewhere that I can view the latest version, please?

I "don't have permission to access /~dpc/draft-spec/" on
http://monet.nag.co.uk/

As someone working from the point of view of implementing the
renderer, I struggled with these sections because they don't
specifically state the "right" behavior. However, I think I just
need to accept that the "right" behavior is not completely
specified.

IMO, it would be best if MathML were as specific as possible (and
maybe it is for now). I understand though that this is a not an
easy issue to completely specify the "right" behavior in all
situations. I also wonder whether some may have pushed for the
spec to change because existing implementations do not follow the
old spec. That on its own is not a good enough reason to change
the spec IMO, so I hope that is not the reason.

As long as it is made clear that authors cannot expect any
specific behavior when there is no one "right" behavior, then I
think we are at a reasonable point in the process of continual
improvement.

Karl.

RE: [MathML3-last-call] media-types mentioned in encoding attributes

2009-11-22T12:31:32Z

[MathML3-last-call] media-types mentioned in encoding attributes

Hi. This message records the resolution of the last call comment quoted below. The changes were:

- fixing incorrect casing of the encoding attribute values MathML, MathML-Presentation

and MathML-Content in chapters 3, 5 and 6.

- changing the encoding to application/vnd.wolfram.mathematica for the Mathematica example.

- changing the encoding to application/x-tex for the examples of TeX annotations

--Robert

CVS logs:

presentation-markup.xml
revision 1.307
date: 2009/11/22 19:05:12; author: rminer; state: Exp; lines: +2 -2
corrected casing of encoding values

mixing.xml
revision 1.127
date: 2009/11/03 22:22:17; author: rminer; state: Exp; lines: +2 -2

world-interactions.xml
revision 1.67
date: 2009/11/22 19:05:13; author: rminer; state: Exp; lines: +3 -3
corrected casing of encoding values

Dr. Robert Miner
Vice President, Research and Development
 
Design Science, Inc.
140 Pine Avenue, 4th Floor
Long Beach, California 90802
USA
Main:   (562) 432-2920
Direct: (651) 223-2883
Fax:    (651) 292-0014
robertm@...
www.dessci.com

From: www-math-request@... on behalf of Paul Libbrecht
Sent: Wed 10/7/2009 8:03 AM
To: Public MathML mailing list
Subject: [MathML3-last-call] media-types mentioned in encoding attributes

Hello all,

MathML3 now define three media-types in the appendix B, this is the
objective of another mail I will send to ietf-types. My objective is
to discuss the encoding attribute values within examples.

Since MathML3, the annotation and annotation-xml elements carry the
encoding attribute with the following recommended content:
1.- MathML-Presentation
2.- MathML-Content
3.- MathML
4.- the media-type of the annotation
5.- some text value you expect someone will recognize

If you look at the specification we have the following example values;
I note that there are spurious occurrences of versions of 1, 2, and 3
with a different casing which we should clean. Aside of 1, 2, and 3
there are:

- well known media-types: image/png, text/plain, application/xhtml
+xml, image/tiff, image/svg+xml. No issues here.

- not yet standardized media-types:

-- application/openmath+xml: should probably be done by the OpenMath
society one day, this follows directly RFC-3023 so there's no big
debate here

-- application/x-maple: is justified by some documentation pages on
MapleSoft's documentation and a private email exchange with Andrew
Smith of MapleSoft. This is done for the sake of an "unregistered
media type".

-- application/mathematica has been requested to change by Jason
Harris of Wolfram Research to
application/vnd.wolfram.mathematica
in the mail I reproduce below. I hereby propose to perform this change.

- non-standardized string: TeX, For this type, I have to say, there is
no standard and it seems impossible to safely define one. We could
replace it by application/x-tex which is what the Apache server
delivers for a .tex file. On this point, I request suggestions.

thank you in advance for your comments.

paul

> De : Jason Harris <...>
> Date : 1 octobre 2009 19:17:04 GMT+02:00
> À : paul@...
> Objet : Rép : MathML3 followup [TS 37366]
>
> [...]
> ----------------
>
> For the MathML 3 sepc, can someone update the draft in the
> appropriate places to reflect the following change: Mathematica's
> MIME type will change in the next version.
>
> In detail:
> We're registering new MIME types for future versions of
> Mathematica. The one which would replace application/mathematica
> is...
>
> application/vnd.wolfram.mathematica
>
> Assuming this is accepted by IANA (We have already received initial
> comments with only minor requests for updates, so I have no reason
> to expect a rejection), this is what we'll use in future versions of
> Mathematica. application/mathematica will become a legacy type.
>
> One of the differences in application/vnd.wolfram.mathematica is
> that the version specification is now *optional*, not required.
>
> Sincerely,
>
> Jason Harris
> Wolfram Research
> [....]

Re: [Entities-last-call] U02220-020D2 , five hexadecimal digits,...

2009-11-22T04:20:50Z

> I prefer hexadecimal Unicode code point numbers to have four or six
> digits. May be that is old-fashioned and byte-oriented. But five digit
> numbers hurt my eyes especially in columns with the title "BMP".

In the editors draft we now use U+ notation consistently eg

http://www.w3.org/2003/entities/2007doc/sans-serif-bold-italic.html

The unicode standard, where it introduces this notation, says to only pad
with 0's if there are less than 4, so it seems 5 digits is the correct
form for the plane 1 characters, but we are now using 4 digts for BMP
references as you suggested, thanks.

http://www.unicode.org/versions/Unicode5.0.0/appA.pdf

> .... Leading zeros are omitted, unless the code point would have fewer
than four hexadecimal digits for example, U+0001, U+0012, U+0123,
U+1234, U+12345, U+102345.

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: [Entities-last-call] - bfsfit glyphs

2009-11-22T04:06:41Z

me> It's 10 years ago and I'm not sure I have the sources, but I did
me> tweak the metafont parameters taking a creative merge of the bold,
me> slanted and sans serif parameters to come up with a bold sans serif
me> slanted. Perhaps I wasn't creative enough, I agree it could be
me> more bold.

Actually it was only 9 years, October 2000 seems to have been the last
time I touched those sources...

Will> It wasn't the absolute weight that I was worried about, just that it
Will> looked like the same glyphs were being used for normal weight slanted
Will> sans serif as well.

They din't only look similar: cmp confirmed the png files were identical.
So despite there being a start of some mf sources for this, it appears
that I just used the normal weight ones.

Rather than switch to Stix beta here I decided to stick with the
Computer Modern heritage of (almost) all the rest and have tweaked the
metafont a bit more resulting in an updated set of bold slanted sans
glyphs as can be seen in the editors' draft:

http://www.w3.org/2003/entities/2007doc/sans-serif-bold-italic.html

Thanks for reporting this,

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

[MathML-Last-Call] Table of pseudo-script characters

2009-11-20T12:27:05Z

The table of pseudo-script characters in section 7.7.2
contains some omissions and other editorial issues.

Here is the updated table:

U+0022 QUOTATION MARK
U+0027 APOSTROPHE
U+002A ASTERISK
U+0060 GRAVE ACCENT
U+00AA FEMININE ORDINAL INDICATOR
U+00B0 DEGREE SIGN
U+00B2 SUPERSCRIPT TWO
U+00B3 SUPERSCRIPT THREE
U+00B4 ACUTE ACCENT
U+00B9 SUPERSCRIPT ONE
U+00BA MASCULINE ORDINAL INDICATOR

U+2018 LEFT SINGLE QUOTATION MARK
U+2019 RIGHT SINGLE QUOTATION MARK
U+201A SINGLE LOW-9 QUOTATION MARK
U+201B SINGLE HIGH-REVERSED-9 QUOTATION MARK
U+201C LEFT DOUBLE QUOTATION MARK
U+201D RIGHT DOUBLE QUOTATION MARK
U+201E DOUBLE LOW-9 QUOTATION MARK
U+201F DOUBLE HIGH-REVERSED-9 QUOTATION MARK

U+2032 PRIME
U+2033 DOUBLE PRIME
U+2034 TRIPLE PRIME
U+2035 REVERSED PRIME
U+2036 REVERSED DOUBLE PRIME
U+2037 REVERSED TRIPLE PRIME
U+2057 QUADRUPLE PRIME

In addition, the characters in the Unicode Superscript and Subscript block
(U+2070 through U+2094) should be treated as pseudo-scripts when they
appear in mathematical formulas.

Sam

Checking in character-set.xml;
/w3ccvs/WWW/Math/Group/spec/xml/character-set.xml,v <-- character-set.xml
new revision: 1.107; previous revision: 1.106
done

Re: [MathML3-last-call] mathvariant

2009-11-20T10:51:21Z

Resolved with improved wording for sections 3.2.2 and 7.5.

/w3ccvs/WWW/Math/Group/spec/xml/character-set.xml,v <-- character-set.xml
new revision: 1.106; previous revision: 1.105
done

Details below.

Sam

Changed the text in sections 3.2.2 and 7.5 that describes mathvariant
to be more inclusive of other combinations, including bold italic dotless
i/j and Greek digammas, without mandating which combinations a renderer
should visually distinguish.

Changed the text to be more specific about when certain combinations
of character data and mathvariant values are equivalent to assigned
Unicode code points that encode mathematical alphanumeric symbols.

Section 7.5 has been fixed to enumerate the characters that represent
holes in the plane 1 alphabetic sequences.

In principle, any mathvariant value may be used with any character
data to define a specific symbolic token. In practice, only certain
combinations of character data and mathvariant values will be visually
distinguished by a given renderer.

The references in section 7.5 to Unicode 3.1 have been changed to ensure
that the definition of mathvariant does not depend on a specific version
of Unicode.

At 08:51 AM 10/13/2009, Sam Dooley wrote:
>Partially resolved with improved wording for section 3.2.2.
>
>/w3ccvs/WWW/Math/Group/spec/xml/presentation-markup.xml
>new revision: 1.281; previous revision: 1.280
>
>Section 7.5 still needs updating to track changes in section 3.2.2.
>
>Sam

Re: [MathML3-last-call] add a notion of "natural" direction for operators to prevent weird stretching

2009-11-20T01:45:44Z

That sounds perfectly good to me. Thanks.

> "There is no provision in MathML for specifying in which direction
> (horizontal or vertical) to stretch a specific character or operator;
> rather, when stretchy="true" it should be stretched in each direction
> for which stretching is possible and reasonable for that character.
> It is up to the renderer to know in which directions it is reasonable to
> stretch a character, if it can stretch the character."
>
> We would appreciate a response by Monday as to whether this change is
> satisfactory to you -- we need to record all responses so that we can
> submit documentation to request moving to a Candidate Recommendation
> phase.

Re: [MathML3-last-call] add a notion of "natural" direction for operators to prevent weird stretching

2009-11-19T17:42:31Z

Frédéric,

My apologies for this late reply. In reviewing last call comments, it appears that no one ever responded to your comment.

The WG discussed your ideas and agreed with you that the text could use some clarification that stretchy="true" does not require stretching a character in all possible directions. The new language is:

"There is no provision in MathML for specifying in which direction
(horizontal or vertical) to stretch a specific character or operator;
rather, when stretchy="true" it should be stretched in each direction
for which stretching is possible and reasonable for that character.
It is up to the renderer to know in which directions it is reasonable to
stretch a character, if it can stretch the character."

/w3ccvs/WWW/Math/Group/spec/xml/presentation-markup.xml,v <-- presentation-markup.xml
new revision: 1.306; previous revision: 1.305

We would appreciate a response by Monday as to whether this change is satisfactory to you -- we need to record all responses so that we can submit documentation to request moving to a Candidate Recommendation phase.

Thanks,

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

In section 3.2.5.8 "Stretching of operators, fences and accents", it is
written that an operator should be stretched in each possible direction:

"There is no provision in MathML for specifying in which direction
(horizontal or vertical) to stretch a specific character or operator;
rather, when stretchy="true" it should be stretched in each direction
for which stretching is possible. It is up to the renderer to know in
which directions it is able to stretch each character."

Currently, it seems that the stretching directions that one would
expect for an operator are only determined by the technical constraints
imposed to the renderer. Nevertheless, this overlooks the fact that
renderer could use techniques to make possible stretching in both
direction, for any single character. For instance, some graphics library
allow "scale transform" (as defined in chapter 7 of SVG rec) that can be
used for this purpose. In that case, some weird stretching could happen
such that a vertical arrows stretched horizontally.

Hence I suggest to add a notion of "natural" direction that will be
used when an operator needs to be stretched (with either a default or
explicit stretchy=true). For instance the working draft already suggests
"vertical" direction for most fences, "horizontal" direction for some
accents, and both directions for diagonal arrows. Apart from the
examples given in the working draft, it would of course be up to the
renderer to determine what direction is "natural" for a given operator.
For example, an integral symbol is likely to be defined as "naturally"
vertical.

Re: [MathML3-last-call] comments from HTML WG

2009-11-19T12:09:42Z

(Not speaking on behalf of anyone or suggesting any spec changes, just
commenting on a few things I saw here...)

David Carlisle wrote:
>> 8. In the section describing color[3] you reference color names from
>> HTML4. Is there a reason MathML doesn't use css3-color SVG color
>> keywords instead of HTML4 color keywords?
>
> Initially (MathML1) there was no css3-color or svg.
> We did look briefly at extending this list but it wasn't clear that this
> would be useful: it doesn't really add any new functionality (since hex
> colours are supported)

Using CSS3 Color could add RGBA functionality, which would be new. (Not
saying it's necessarily a good idea, though!)

> and typically isn't currently supported by MathML2 systems.

SVG colors seem to be supported by Firefox 3.5:
data:application/xml,<math%20xmlns="http://www.w3.org/1998/Math/MathML"><mi%20mathcolor='tomato'>Test</mi></math>
(I can't say anything about other MathML systems, though.)

> HTML5 has these extended color names but introduces
> them as
>
> "Some obsolete legacy attributes parse colors in a more
> complicated manner,"
>
> which doesn't really encourage these colours to be added as a new feature
> to other specs such as MathML3

The obsoleteness is about the attributes and the parsing algorithm,
rather than about the colours - that part of the spec is needed for
cases like <body bgcolor="cheese"> (a nice greenish yellow colour, since
it's parsed like #c0ee0e (for legacy reasons), and it's non-conforming
anyway because bgcolor is never allowed).

As far as I can see, the only place HTML5 uses colours in a non-obsolete
fashion is for <canvas>, and there it refers to CSS3 Color for the full
list of colour types and keywords. All other uses of colour in a web
browser are just CSS, so HTML5 is not involved in the definition of
that; browsers largely follow CSS3 Color there.

--
Philip Taylor
pjt47@...

Re: [MathML-Last-Call] Inherited attributes and default values

2009-11-19T12:04:42Z

Fixed, as follows.

1) Changed the default value of displaystyle on mtable to
"inherited (false)".

Added text to describe that mtable makes an automatic change of the
value of displaystyle to "false" if the attribute is not present.

2) Added text to describe that mscarries makes an automatic change of
the value of displaystyle to "false".

3) Changed the default value of scriptsizemultiplier on mscarries to
"inherited (0.6)".

Added text to describe that mscarries changes the default value of
the inherited scriptsizemultiplier to 0.6. The effect is that the
inherited value should override the default value, but the default
value, inside mscarries, should be 0.6.

Sam

Checking in presentation-markup.xml;
/w3ccvs/WWW/Math/Group/spec/xml/presentation-markup.xml,v <-- presentation-markup.xml
new revision: 1.304; previous revision: 1.303
done

At 11:57 AM 11/9/2009, Sam Dooley wrote:

>The mstyle element (section 3.3.4.1) specifies that an attribute that
>is not normally inherited, such as linethickness on mfrac, may have a
>default value that may be changed by an attribute on mstyle.
>
>Some clarification is needed for cases of inherited attributes that are
>given default values on other elements. The troublesome attributes are
>displaystyle and scriptsizemultiplier.
>
>If the default value should override the inherited value, then mstyle
>cannot be used to change the default value, as it is described to do
>for other attributes. If the inherited value should override the
>default value, then the default value for these attributes has no
>meaningful effect.
>
>Suggested changes:
>
>1) displaystyle on mtable (section 3.5.1)
>
>displaystyle on mtable should be marked as an inherited attribute,
>and the text should describe that mtable makes an automatic change
>to set displaystyle to false if the attribute is not present.
>
>This is how displaystyle is described for other elements that make
>automatic changes to displaystyle and/or scriptlevel.
>
>As on other elements, the automatic change should override the
>inherited value.
>
>2) displaystyle on mscarries (section 3.6.5)
>
>The mscarries element should make an automatic change to set
>displaystyle to false, to match other elements that change the
>scriptlevel.
>
>As on other elements, the automatic change should override the
>inherited value.
>
>3) scriptsizemultiplier on mscarries (section 3.6.5)
>
>scriptsizemultiplier on mscarries should be marked as an inherited attribute,
>and the text should describe that mscarries makes an automatic change to the
>default value that is used in its child elements. The description should
>specify that while mscarries changes the default value, it uses the inherited
>value if one has been set.
>
>This way, mstyle can be used to supply the inherited value for mscarries,
>and mscarries can use the specialized default value if the inherited value
>has not been set by mstyle.

Re: [MathML3-last-call] comments from HTML WG

2009-11-19T09:31:59Z

Shelley, HTML WG,

Thank you for your comments.

As noted below we have fixed the definite mistakes that you reported
and have tried to add clarifying text to address the other issues you
raised. The results can be seen at the editors' draft

http://monet.nag.co.uk/~dpc/draft-spec/chapter2.html#fund.attval

> Following are some general comments about the MathML 3.0 draft from
> the HTML WG, particularly as the MathML specification relates to
> current effort with HTML5. First, though, we wish to extend to the
> Math WG congratulations for reaching this important milestone.
>
> Related to the addition of the new href attribute[1]:
>
> 1. The attribute href has been added for use with several MathML
> elements, rather than using xlink:href, from MathML 2.0. However, the
> document states that because of compound document requirements,
> xlink:href can still be used. This could cause confusion when viewing
> the documentation for MathML as foreign object in HTML5. In the HTML5
> specification, if the href attribute is associated with the XLink
> namespace, it must be given as xlink:href in the document.
>

Foreign namespaced attributes are allowed in MathML3, as they are in
earlier versions of MathML, so syntactically xlink attributes are allowed
by general principles, but the MathML3 spec is quite explict that href is the
preferred form for use as a hyperlink. We have adjusted the text in
section 6 to make this clearer and to give advice to existing
mathml2+xlink applications.

RCS file: /w3ccvs/WWW/Math/Group/spec/xml/world-interactions.xml,v

revision 1.59
date: 2009/11/18 04:08:00; author: rminer; state: Exp; lines: +19 -14
linking rewrites

> The MathML href attribute is now, by default, associated with the
> MathML namespace. But this isn't specifically stated in the document,

Like all unprefixed attributes it is in no namespace. It is not
associated with the MathML namespace, thus we do not know what
statement you expected to see here, we are assuming no change is
required to the document. If you feel some clarification is needed,
please respond further on this point.

> and someone reading both may become confused, and assume they have to
> use xlink:href with MathML embedded in HTML5.

xlink:href was only mentioned in passing in one or two places,
discussing differences with MathML2 so we were not sure why you thought
someone would have to use xlink, but as noted above we have
adjusted the wording in section 6.4.2 Linking to try to make this
clearer.

> The document may want to
> demonstrate how href can be used with embedded MathML in the document
> section detailing MathML embedded in HTML.

This section has been rewritten, href should not really need an example,
it takes a URI (LEIRI) as value and is used exctly the same way as a
href in html for example.

>
> 2. Is the plan to drop support for xlink:href in MathML UAs at some
> point? If not, we're curious as to why the Math WG introduced the new
> attribute?

xlink was not widely supported amongst mathml2 UAs in any case, for
example as far as we can tell it doesn't work in any current browser
implementation of mathml (although it has worked in firefox)

xlink is a separate specification which user agents may or may not wish
to implement, the MathML spec can not say what other specifications
should be implemented by applications. We have revised the text in 6.4.2
to give advice on what an application supporting both xlink and native
mathml linking should do. The issue here though is just the same as in
xhtml, if an application supports xlink and xhtml there is the
possibility of having both href and xlink:href on the same element.

>
> 3. If the UA supports both, what should happen when both are specified
> on one element?

Formally this is out of scope for MathML, however we have given some
advice that href be preferred in the revised linking section.

>
> 4. We're also curious as to why the new href attribute takes a URI
> rather than IRI?

Thanks for catching this, we will add some clarifying text.

Most XML related specifications (including XML itself and XSD) as well
as MathML use "URI" (or "URL" in older specs such as XML or MathML1) to
mean essentially what is now known as an IRI (or differing in some edge
cases, a LEIRI). The MathML attributes that are described as type URI
are actually XSD schema typed as xs:anyURI which means that they have a
lexical space of any string and the system is supposed to %-encode any
characters not allowed in URI. Effectively this means that they take an
IRI. We have added wording to the table of common attribute types in
2.1.5 where this attribute type is introduced.

http://www.w3.org/TR/MathML3/chapter2.html#fund.attval

Adding reference for URI to both the current IRI RFC,

http://www.ietf.org/rfc/rfc3987.txt

and its proposed update

http://tools.ietf.org/html/draft-duerst-iri-bis-07

$ cvs commit -m IRI fundamentals.xml references.xml
Checking in fundamentals.xml;
/w3ccvs/WWW/Math/Group/spec/xml/fundamentals.xml,v <-- fundamentals.xml
new revision: 1.127; previous revision: 1.126
done
Checking in references.xml;
/w3ccvs/WWW/Math/Group/spec/xml/references.xml,v <-- references.xml
new revision: 1.90; previous revision: 1.89
done

>
>
> Related to the Chapter 6.4, Combining MathML and Other Formats, and
> specific to 6.4.1, Mixing MathML and HTML:
>
> 5. The specification includes a section discussing MathML and HTML.
> However, the section only references MathML in XHTML. With HTML5,
> MathML can be used in HTML, and there are additional constraints on
> using MathML in HTML, including the fact that the outer math element
> is specified without a prefix (such as m:math, as shown in the
> example), though the use of a namespace and prefix can work with
> XHTML.
>
> There are other constraints associated with MathML in HTML. Could this
> one section be split in two, with one section detailing MathML in
> XHTML, and one in HTML?
>
> In particular, HTML allows unquoted attributes, and elements without
> closing tags (if such are given in the list of allowed elements
> without closing tags). These looser specifications also apply to
> foreign
> objects such as SVG and MathML (though user agents are encouraged to
> provide an export facility providing properly formatted XML). However,
> people can paste properly formatted XML into HTML, and it will be
> supported.

The existing MathML+HTML section in chapter 6 has been split into two,
one for XHTML and one for non-xml syntaxes, specifically HTML5.

Note however the MathML specification defines MathML as an XML
application, if other specifications define mathml variants with
different syntax then it is that specification that must specify
the differences. (HTML5 effectively does that by specifying how
the html-like syntax is parsed to an xml dom).

$ cvs commit -m html5 references.xml world-interactions.xml
Checking in references.xml;
/w3ccvs/WWW/Math/Group/spec/xml/references.xml,v <-- references.xml
new revision: 1.91; previous revision: 1.90
done
Checking in world-interactions.xml;
/w3ccvs/WWW/Math/Group/spec/xml/world-interactions.xml,v <-- world-interactions.xml
new revision: 1.62; previous revision: 1.61
done

>
> Pasting MathML into HTML does lead to another issue: the use of
> namespaced attributes. Namespaced attributes can be included in
> MathML, but, currently, the validator does provide a warning for
> namespaced attributes in SVG or MathML when embedded in HTML. The same
> applies to properly formatted XML entities and attributes that might
> be included within the MathML annotation-xml
> element.

The behaviour of namespaced attributes is entirely implementation
defined, they are allowed but no particular behaviour is mandated, so if
for example they were just ignored by HTML systems that would be
conformant, doing more would be helpful to the user, but not mandated.

>
> In addition, there are also, currently, DOM namespace handling
> differences associated with MathML pasted into HTML, as compared to
> MathML pasted into XHTML.
>

The MathML3 spec does not discuss the DOM at all, so while this might be
true it does not affect the MathML3 specification. If we decide later to
update the MathML2 DOM to a separate MathML3 DOM specification, this
might become an issue.

> Both the DOM differences and the validator warnings, in addition to
> the syntax differences, such as unquoted attribute values, might be
> surprising and confusing to folks who expect properly formatted XML in
> HTML.
>

As noted above, the MathML specification only defines the XML syntax.
If other specifications introduce syntactic variants, then any issues
must be addressed in those specifications. However as HTML is an
important special case, a mention of unquoted attributes in html is given
as an example in the new html-specific section in chapter 6.

> 6. The section contains the following passage:
>
> "To fully integrate MathML into XHTML, it should be possible not only
> to embed MathML in XHTML, as described in Section 6.2.1 Recognizing
> MathML in XML, but also to embed XHTML in MathML. However, the problem
> of supporting XHTML in MathML presents many difficulties. Therefore,
> at present, the MathML specification does not allow XHTML elements
> within a MathML expression, although this situation may be subject to
> change in a future revision of MathML."
>
> What are the difficulties referenced in the document?
>
> In particular, the HTML5 parser supports HTML and SVG in <mi>, <mo>,
> <mn>, <ms>, <mtext> and SVG in <annotation-xml>. XHTML and SVG in
> MathML in these places works fine in Firefox and Opera today when
> using application/xhtml+xml. We're curious as to why MathML doesn't
> allow what is, at a minimum, expressible in text/html?
>

the quoted section has been rewritten as that section has been split in
two, as noted above so that HTML and XHTML can be discussed separately.

Also, please refer to the reply given to the I18n group on a similar question.

http://lists.w3.org/Archives/Public/www-math/2009Nov/0010.html

The normative schema for MathML needs to restrict to text in for the
reasons given. XHTML+MathML, being defined by a schema could use a more
open schema that allowed nested XHTML elements. MathML in HTML5, being
defined by the prose text of the HTML5 parse rules is defined by that
specification not by MathML.

It would be entirely wrong for the normative MathML schema to say that
(X)HTML elements are by default allowed inside mtext. MathML as used by
computer algebra systems (for example) probably can not deal with
structured text at all, and docbook+MathML or XSL-FO+MathML (for
example) would typically be processed by systems that could handle
embedded docbook (or XSL-FO) elements in mtext but not HTML. This is why
it needs to be the decision of the person defining the compound document
format (XHTML+MathML or HTML+MathML) whether to allow nested HTML inside
mtext. Even in a purely HTML+MathML application it isn't always
possible to support nested HTML elements and mandating it would make
some highly used systems non compliant. In a component architecture such
as used by IE, if a different component is being used to render the
MathML, it can not (given current API) easily call back to the host
browser to render nested instances of HTML.

>
> Other, general comments:
>
> 7. In the element listing [2] you show an element labelled td, but the
> link associated with it leads to a section describing an element
> labeled mtd. Possible typo?

Thanks for catching this.

That list is automatically generated from the xmlspec markup and it is
highlighting a typo in 3.5.4.2 Attributes where td was used for
mtd.

This has been fixed in our sources.

$ cvs commit -m "td to mtd" presentation-markup.xml
Checking in presentation-markup.xml;
/w3ccvs/WWW/Math/Group/spec/xml/presentation-markup.xml,v <-- presentation-markup.xml
new revision: 1.292; previous revision: 1.291
done

>
> 8. In the section describing color[3] you reference color names from
> HTML4. Is there a reason MathML doesn't use css3-color SVG color
> keywords instead of HTML4 color keywords?

Initially (MathML1) there was no css3-color or svg.
We did look briefly at extending this list but it wasn't clear that this
would be useful: it doesn't really add any new functionality (since hex
colours are supported) and typically isn't currently supported by
MathML2 systems. HTML5 has these extended color names but introduces
them as

"Some obsolete legacy attributes parse colors in a more
complicated manner,"

which doesn't really encourage these colours to be added as a new feature
to other specs such as MathML3

Adding the long list of X11/SVG colour names to MathML3 at this time
would hurt interoperability with existing MathML systems that do not
support them, and offers no real extra features (as the colours may be
specified using the hex rgb syntax). Supporting the extended list imposes
a non negligable implementation cost on any implementation that is not
hosted in a CSS environment that already supports these colours.

>
> 9. The index lists two values, my:background and my:color, which are
> also demonstrated in the section to which they're linked. These would
> seem to be from demonstrations of bringing in color or background from
> another namespace. Including them in the index could generate
> confusion.

The index (which is automatically generated) indexes the use of these
attributes. Why do you think it confusing to index an example that is
there? Perhaps you mean that the example is confusing, but if so could
you give some indication of what in particular causes confusion or what
could be changed to lessen the confusion.

>
> Shelley Powers
> HTML WY
>
> [1] http://www.w3.org/TR/2009/WD-MathML3-20090924/chapter2.html#fund.globatt
> [2] http://www.w3.org/TR/2009/WD-MathML3-20090924/appendixh.html#index.elem
> [3] http://www.w3.org/TR/2009/WD-MathML3-20090924/chapter2.html#type.color
>
>

David Carlisle
For the Math WG

________________________________________________________________________
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: [Entities-last-call] - missing entities in w3centities-f.ent

2009-11-19T09:06:56Z

yes sorry, I just noticed that last night. I messed up the arguments to
sort. I wanted to change the sort order to bring AMP and amp together but
I actually coalesced them.

Corrected file has been committed.

thanks for reporting this.

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

[Entities-last-call] - missing entities in w3centities-f.ent

2009-11-19T08:31:51Z

The definitions of the lowercase equivalents of the HTML5-UPPERCASE
set (namely amp, copy, gt, lt, quot, reg, and trade) do not exist in
w3centities-f.ent, even though they still appear in the xhtml1-lat1.ent
and xhtml1-special.ent files.

Please fix.

--
John Cowan cowan@... http://www.ccil.org/~cowan
Most people are much more ignorant about language than they are about
[other subjects], but they reckon that because they can talk and read and
write, their opinions about talking and reading and writing are as well
informed as anybody's. And since I have DNA, I'm entitled to carry on at
length about genetics without bothering to learn anything about it. Not.
--Mark Liberman

Re: [Entities-last-call] - bfsfit glyphs

2009-11-18T17:40:46Z

Hi David,

On 18/11/2009, at 8:15 PM, David Carlisle wrote:

>> The glyphs shown as examples for sans serif bold italic look as if
>> they're from the regular weight:
>
> It's 10 years ago and I'm not sure I have the sources, but I did
> tweak the metafont parameters taking a creative merge of the bold,
> slanted and sans serif parameters to come up with a bold sans serif
> slanted. Perhaps I wasn't creative enough, I agree it could be
> more bold.

It wasn't the absolute weight that I was worried about, just that it
looked like the same glyphs were being used for normal weight slanted
sans serif as well.

> I recently discarded my script and bold script glyphs (which were
> identical) and replaced them with glyphs derived from the stix beta.
> perhaps I should do the same here?

The results would certainly look better; not the end of the world
either way, of course :)

-- Will

Re: [Entities-last-call] U02220-020D2 , five hexadecimal digits,...

2009-11-18T13:55:46Z

Matthias,

>
> http://www.w3.org/TR/2009/WD-xml-entity-names-20091117/glyphs/022/U02220-020D2.png
> seems to point to an existing file. Nevertheless it shows a placeholder only.
>

Ah thanks for that, The png works in firefox but not in IE. That's
happened before occasionally, previously if I use imagemagic convert to
convert the png (to anything and back again) it will warn of some
internal inconsistency and fix it up....

$ convert U02220-020D2.png x.gif
convert: Incorrect tRNS chunk length `U02220-020D2.png'.

David Carlisle@dcarlisle /home/w3c/WWW/2003/entities/2007doc/glyphs/022
$ convert x.gif U02220-020D2.png

David Carlisle@dcarlisle /home/w3c/WWW/2003/entities/2007doc/glyphs/022
$ cvs commit -m "bad chunk length" U02220-020D2.png
Checking in U02220-020D2.png;
/w3ccvs/WWW/2003/entities/2007doc/glyphs/022/U02220-020D2.png,v <-- U02220-020D2.png
new revision: 1.2; previous revision: 1.1
done

yes seems to work now, try the editor's draft at

http://www.w3.org/2003/entities/2007doc/U020D2.html

thanks.

> I prefer hexadecimal Unicode code point numbers to have four or six
> digits. May be that is old-fashioned and byte-oriented. But five digit
> numbers hurt my eyes especially in columns with the title "BMP".

original versions of these tables (in mathml, going back a decade or so)
used the internal U01234 form pretty much everywhere: this form has
advantages in the internal build as it's a valid XML ID (unlike U+ form
which can't be used as an XML ID value, and consistently using 5 digits
allows things to be sorted naively (until someone pushes some
interesting characters in the 6 digit range;-) however in the visible
text of the specification we've almost completely switched to using the
Unicode U+1234 form, just using the original form for internal
identifiers, and png file names, so I suppose it makes sense to catch
the remaing cases as well. All the tables are generated so changing
notation isn't a big deal just a matter of dropping in a suitable
regular expression replace. I'll see what I can do.

> What is the reason to show duplicates like " oplus, oplus, CirclePlus
> ".

well they are dupicated because (in the case of oplus) the name is both
in xhtml-symbol and in isoamsb, but since I don't show the set name
there the duplication is not very helpful, .....
I just checked in the stylesheet with distinct-values() xpath functin inserted

and the editors' draft now just shows these just once:

http://www.w3.org/2003/entities/2007doc/U020D2.html

Thanks for your comments.

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

[Entities-last-call] U02220-020D2 , five hexadecimal digits,...

2009-11-18T09:50:05Z

Hello.

I read http://www.w3.org/TR/2009/WD-xml-entity-names-20091117/ and I also read a copy of a long list of comments written by Martin Dürst.

I am impressed by all the detailed work which has been done.

Many important comments are already written by Martin.

Only some few tiny comments:

(1)
http://www.w3.org/TR/2009/WD-xml-entity-names-20091117/glyphs/022/U02220-020D2.png seems to point to an existing file. Nevertheless it shows a placeholder only.

(2)
I prefer hexadecimal Unicode code point numbers to have four or six digits. May be that is old-fashioned and byte-oriented. But five digit numbers hurt my eyes especially in columns with the title "BMP".

(3)
http://www.w3.org/TR/2009/WD-xml-entity-names-20091117/U0FE00.html ,
http://www.w3.org/TR/2009/WD-xml-entity-names-20091117/U020D2.html ,
http://www.w3.org/TR/2009/WD-xml-entity-names-20091117/U020D2.html show a variable number of Entity Names. What is the reason to show duplicates like " oplus, oplus, CirclePlus ".

Best regards,

Matthias Mittelstein

Development Architect
TD Core AS&VM ABAP Infratructure
TD Core ABAP Server and VM Technology
BST Technology Develoment Core
BST Technology Develoment
Business Solutions & Technology
SAP AG
Großer Grasbrook 17
20457 Hamburg
T +49 40 22707 131
T +49 6227 7 61164
F +49 6227 78 00295
mailto:matthias.mittelstein@...
www.sap.com
Pflichtangaben/Mandatory Disclosure Statements: http://www.sap.com/company/legal/impressum.epx
Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.

Re: [Entities-last-call] - bfsfit glyphs

2009-11-18T01:45:22Z

> The glyphs shown as examples for sans serif bold italic look as if
> they're from the regular weight:

It's 10 years ago and I'm not sure I have the sources, but I did
tweak the metafont parameters taking a creative merge of the bold,
slanted and sans serif parameters to come up with a bold sans serif
slanted. Perhaps I wasn't creative enough, I agree it could be
more bold.

I recently discarded my script and bold script glyphs (which were
identical) and replaced them with glyphs derived from the stix beta.
perhaps I should do the same here?

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

[Entities-last-call] - bfsfit glyphs

2009-11-17T21:27:44Z

Hello,

The glyphs shown as examples for sans serif bold italic look as if
they're from the regular weight:
<http://www.w3.org/TR/2009/WD-xml-entity-names-20091117/sans-serif-bold-italic.html
>

Not that there exists a regular weight for Greek sans :)

-- Will