> But if I read this (made by WebEq)
> I will know nothing about stretching of '<' and '>'.
The MathML recommendation isn't very explicit (to put it mildly:-) about
what exactly the definition of the entities should be.
in the tables that I announced on this list last week, I have
<!ENTITY langle CDATA "〈" -- u+3008 left angle bracket MMALIAS lang-->
<!ENTITY LeftAngleBracket CDATA "〈" -- u+3008 left angle bracket MMALIAS lang-->
ie they are both declared as CDATA pointing at the unicode
character. this means that after passing through an SGML parser (ie
__before__ the style sheet sees the data) the two inputs
⟨, ⟨ 〈 or any other method of entering
that character will all have been normailsed to the same thing.
My version of the operator dictionary does key on things like
⟨ (or at least it will once it's all written) but since
the dsssl source is also passed through the SGML parser before being
passed to the style engine, this will similarly be normalised.
Given that in order to cope with things lime "max" they keys have to be
character strings, I would not like to see the type changed to numbers
for the other operators.
> For single characters and &Entities; we should supply unicod numbers.
I read the report as meaning that it is always a character string,
understood in XML encoding thus
as it appears in the operator dictionary is a __single__ character, just
entered as an entity in a 7bit encoding to make it more readable to a
human reader who may not have a reader with a sufficiently full unicode
I should say of course that I have no knowledge as to what was intended
by whoever wrote the table. I, like you, am just someone on the outside
trying to implement this stuff!
- From: Kostya Serebriany <email@example.com>