Re: [XML-Entities] Question regarding some Unicode sequences

On 13/06/2014 07:41, Shervin Afshar wrote:
> Hello David,
>
> Thanks for your response. I understand the situation. Do you think it
> makes sense to add a note to the following paragraph of the working
> draft regarding this issue? (from
> http://www.w3.org/2003/entities/2007doc/#chars_math-multiple-tables)
>
>> "The entities race and acE denote underlined characters for which Unicode does not have codepoints, thus combining underline characters have been used, in a way analogous to the use of combining strokes for negated operators."

Yes I could add something to the editors draft (although whether there 
will be a new REC ever)
is an open question, as I indicated stability is good and the price of 
pulling in HTML means that
stability outweighs almost everything:-)


> Also, a general question comes to mind; what is the policy of MathML
> regarding character entities which are currently not encoded in UCD,
> but might be in the future?
Basically it's too late (the only ones missing now are essentially the 
non combining
multiple dot accents) the bulk of the math characters added in Unicode 
3.1 -6 were
added due to the STIX proposal aided and abetted by the needs of this 
entity set.
(bold digamma and dotless j in particular added specifically for this 
set), but now
even if Unicode did add a non combining triple dot accent I don't think 
we could
change tdot any more than we can change race.


>   In many cases the mere fact that a
> character is part of MathML repertoire provides a good rationale to
> include it in Unicode. Obviously, being backward compatible is
> essential, but on the other hand, it should be possible to have such
> data added to "unicode.xml" for the reference of contemporary and
> future implementations.

Yes I may see if I can add some markup to unicode.xml to cross reference the
characters that could have been used (and in particular that people may want
to use in controlled private production setups.  I wouldn't recommend using
"improved" definitions in public entity sets, better just to use 
non-clashing names.

David

Received on Friday, 13 June 2014 08:50:34 UTC