Hi all,
I have a quite a few comments to make on this Math fragment
and I see that I am the first to do so...
----------------------------------------
First, I think that it would be a mistake NOT to include the
elements of inline mathematical formatting into the general
%text definition. That is, I must be able to use <SUP> and
<SUB> and some of the other elements within a paragraph, list
or heading.
----------------------------------------
Secondly, perhaps I am the only person among us who isn't familiar
with TeX, and that might make it harder for me to understand or
appreciate some of the constructs that are presented here.
I have some difficulty with the list of EMPTY elements which
are used to more like delimiters in a programming language.
For example, <LEFT> is used to indicate that what came before
is to be placed to the left and <RIGHT> is used to indicate
that what comes next is to be placed to the right. I assume,
not knowing, that this is more or less how TeX would do it.
If you want to use TeX, then why not provide support for TeX
within the browser and provide portable code to the rest of
the community to support it too? Personally, being much more
experienced with EQN, I would like to see it adopted as another
NOTATION supported by HTML browsers.
----------------------------------------
Quoting from the notes I took in Geneva:
"It was noted that the model described by Philip for mathematics
was more accurately a model for fairly precise typographical layout
and would serve the community very well in that capacity. As such,
it could also serve as a means by which mathematics could be layed
out typographically. Nonetheless, for the purposes of publishing
pure mathematics in a notation that could be parsed and unambiguously
interpreted by man or machine, a mathematical NOTATION(s) would be
better suited."
So, I wonder if a content model like this makes any sense to you all:
(I assume that ROOT, SUB and SUP would be part of %text;)
<!ENTITY % formulae "(#PCDATA | BOX | ARRAY)*">
<!ELEMENT MATH - - (LABEL, (%formulae; | A )*)>
<!ELEMEMT LABEL - - ((%text; | A )*)>
<!ELEMEMT BOX - - (LEFT?, ATOP?, CENTER, OVER?, RIGHT?)>
<!ATTLIST BOX ALIGN (left | top | bottom | right)
LDELIM CDATA #IMPLIED
TDELIM CDATA #IMPLIED
BDELIM CDATA #IMPLIED
RDELIM CDATA #IMPLIED
SIZE NUMBER 100 >
<!ELEMENT LEFT - o (LEFT?, TOP?, CENTER, (BOTTOM|OVER)?, RIGHT?)>
<!ELEMENT TOP - o (LEFT?, TOP?, CENTER, (BOTTOM|OVER)?, RIGHT?)>
<!ELEMENT CENTER - o (LEFT?, TOP?, %formulae;, (BOTTOM|OVER)?, RIGHT?)>
<!ELEMENT BOTTOM - o (LEFT?, TOP?, CENTER, (BOTTOM|OVER)?, RIGHT?)>
<!ELEMENT OVER - o (LEFT?, TOP?, CENTER, (BOTTOM|OVER)?, RIGHT?)>
<!ELEMENT RIGHT - o (LEFT?, TOP?, CENTER, (BOTTOM|OVER)?, RIGHT?)>
<!ATTLIST LEFT ALIGN (left | top | center | bottom | right) >
<!ATTLIST TOP ALIGN (left | top | center | bottom | right) >
<!ATTLIST CENTER ALIGN (left | top | center | bottom | right) >
<!ATTLIST BOTTOM ALIGN (left | top | center | bottom | right) >
<!ATTLIST RIGHT ALIGN (left | top | center | bottom | right) >
<!ATTLIST SUB ALIGN (left | top | center | bottom | right) >
<!ATTLIST SUP ALIGN (left | top | center | bottom | right) >
----------------------------------------
The <ABOVE> and <BELOW> that are defined in Dave's fragment become
redundant because this model will allow one to construct them:
<BOX> <CENTER> → <BOTTOM> πr<SUP>2</SUP> </BOX>
or
<BOX> <TOP> → <CENTER> πr<SUP>2</SUP> </BOX>
Furthermore, the browsers could be trained to extend certain characters
across the breadth or over the height of a formatted element, thus
ensuring that parens, brackets, braces, rules and arrows fit the
area appropriately.
But, perhaps I just don't understand and appreciate the added value
that <ABOVE> and <BELOW> would provide.
----------------------------------------
In the definition of <BOX> attributes above, I have used a NUMBER
for the SIZE attribute so that relative size could be indicated.
The deault 100 is meant to be interpreted as 100% of the size
(horizontally or vertically) of the typographic element being matched.
It also occured to me that it might be important to specify left,
right, top and bottom delimiters distinctly rather than trying
to parse multiple values from a single attribute.
----------------------------------------
I would redefine <ROOT> thus:
<!ELEMENT ROOT - - (RADIX?, %formulae)>
<!ELEMENT RADIX - - (%formulae)>
----------------------------------------
I'm not sure that I fully appreciate the <ARRAY> element yet.
I'll wait to hear from others before I comment any further.
----------------------------------------
I see that <B> is redefined to contain %formulae;, but I note
that <I> is not similarly redefined. Why not?
----------------------------------------
<MATH> is defined to include <LABEL> at the end of its content.
Why not have <LABEL> at the beginning and then place it at the
end if that is how you decide to format it? In all of the
DTDs that I have worked on, <TITLE>s and <LABEL>s have always
been placed at the beginning of the content model.
----------------------------------------
>
> -----------------------------------------------------------------------------
> <!--
> Here is my revised DTD for maths. It looks like it will be quite easy
> to parse and layout, as well as being deliberately easy to import LaTeX.
> HTML-Math would clearly benefit from SHORTREF definitions to cut down on
> typing. Indeed it may be practical to use _{..} and ^{..} as short forms
> for SUB and SUP in this way. More work is needed to test this out.
>
> Dave Raggett Thu 8-Sep-94 15:00:21
> -->
>
> <![ %HTML.math [
>
> <!ENTITY % formulae "#PCDATA|BOX|ABOVE|BELOW|ROOT|ARRAY|SUB|SUP|B">
>
> <!-- Use     etc to control spacing. TeX entity names
> are supported as a convenience when converting from LaTeX. -->
>
> <!ELEMENT MATH - - ((%formulae;)*, LABEL?)>
> <!ATTLIST MATH id ID #IMPLIED>
>
> <!ELEMENT LABEL - - (#PCDATA)* -- equation labels -->
> <!ELEMENT B - - (%formulae;)+ -- bold text enhancement -->
>
> <!-- Subscripts and Superscripts
>
> <SUB> and <SUP> are used for subscripts and superscripts.
>
> i j
> X <SUP>i</SUP>Y<SUP>j</SUP> is X Y
>
> i.e. the space following the X disambiguates the binding.
> An alternative offering better control at a cost of verbosity is:
>
> <!ATTLIST (SUB|SUP) ALIGN (left|center|right) #IMPLIED>
> -->
>
> <!ELEMENT (SUB|SUP) - - (%formulae;)+>
> <!ATTLIST (SUB|SUP) ALIGN (left|center|right) #IMPLIED>
>
> <!-- The BOX element acts as brackets. Delimiters are optional and
> stretch to match the height of the box. The OVER element is used
> when you want a line between numerator and denominator. This line
> is suppressed with the alternative ATOP element. You can get
> oversize delimiters with the SIZE attribute. Delimiters are
> specified as a pair of characters, or as a space separated pair
> of string or entity names, e.g. "⌈⌉". You can suppress
> one of the delimiters by using the '.' character.
>
> 1 + X
> <BOX>1 + X<OVER>Y</BOX> is _______
> Y
>
> a + b
> <BOX>a + b<ATOP>c - d</BOX> is
> c - d
>
> <BOX delim="(]">a</BOX> is (a]
>
> <BOX delim="|| ||">a</BOX> is || a ||
>
> The delimiters can also be expressed using the LEFT and RIGHT
> elements as in:
>
> <BOX>[<LEFT>x + y<RIGHT>]</BOX> is [ x + y ]
>
> This is useful with definite integrals when you want the integral
> sign to stretch to match the integrand, e.g.
>
> <BOX>∫<SUB>0</SUB><SUP>N</SUP><LEFT>f(x) dx</BOX>
>
> Note that the default size of integral and related symbols is
> sufficient for most needs.
>
> -->
> <!ELEMENT BOX - - ((%formulae;)*, (LEFT, (%formulae;)+),
> ((OVER|ATOP), (%formulae;)+),
> (RIGHT, (%formulae;)+))>
> <!ATTLIST BOX
> delim CDATA #IMPLIED -- optional stretchy delimiters --
> size (normal|medium|large|huge) normal -- oversize delims -->
>
> <!ELEMENT (OVER|ATOP|LEFT|RIGHT) - O (EMPTY)>
> <!ELEMENT SCOPE O O (%formulae;)*>
>
> <!-- Horizontal line drawn ABOVE contents
> The symbol attribute allows authors to
> supply an entity name for an arrow symbol etc.
> -->
> <!ELEMENT ABOVE - - (%formulae;)+>
> <!ATTLIST ABOVE symbol ENTITY #IMPLIED>
>
> <!-- Horizontal line drawn BELOW contents
> The symbol attribute allows authors to
> supply an entity name for an arrow symbol etc.
> -->
> <!ELEMENT BELOW - - (%formulae;)+>
> <!ATTLIST BELOW symbol ENTITY #IMPLIED>
>
> <!-- Roots - default to square root -->
> <!ELEMENT ROOT - - (%formulae;)*>
> <!ATTLIST ROOT root CDATA #IMPLIED -- e.g. "3" for cube root -->
>
> <!-- LaTeX like arrays. The coldef attribute specifies
> a single letter for each column, which also determines
> how the column should be aligned, e.g. coldef"=ccc"
>
> "l" left
> "c" center
> "r" right
>
> The DELIM attribute behaves the same as for BOX.
> When the LABELS attribute is present, the array
> is displayed with the first row and the first
> column as labels displaced from the other elements.
> In this case, the first element of the first row
> should normally be left blank.
>
> Use &vdots; &vdots; and &ddots; for vertical, horizontal
> and diagonal ellipsis dots. Use &dotfill; to fill an array
> cell with horizontal dots.
> -->
> <!ELEMENT ARRAY - - (AROW)+>
> <!ATTLIST ARRAY
> coldef CDATA #REQUIRED
> delim CDATA #IMPLIED -- optional stretchy delimiters --
> labels (labels) #IMPLIED -- TeX's \bordermatrix style -->
>
> <!ELEMENT AROW - O (ITEM)*>
> <!ELEMENT ITEM - O (%formulae;)*>
> <!ATTLIST ITEM
> align CDATA #IMPLIED -- overide coldef alignment --
> colspan NUMBER 1 -- merge columns as per TABLE --
> rowspan NUMBER 1 -- merge rows as per TABLE -->
> ]]>