Extensibility

Many features of HTML-Math are incrementally extensible by the author and/or the viewer, for either a document, a specific portion of a document, and/or a specific type or pattern of HTML-Math subexpression in a document.

Rationale: Mathematical notation is continually evolving and open-ended. It is not likely that HTML-Math will succeed in specifically including all commonly used notation. Nor is it desirable to freeze its notation at any specific set of operators, or even to require centralized notational extension (such as formal inclusion in successive versions of HTML-Math). Instead it should be possible for authors to declare and use new operations (provided that an algorithm for parsing and rendering author-defined operations is specified).

[If and where possible, the extension method will make use of the CSS proposal for Cascading Style Sheets, perhaps after modifications to that proposal for this purpose. But it is not yet clear that all aspects of HTML-Math extension can or should be handled using CSS. This issue is left for further analysis and discussion. For now, I'll describe extension mechanisms without specifying which of them will be an application of CSS and which will be something else.]

The extensible features can be divided into certain classes, listed, named, and discussed below.

[The details of how these features are specified remains to be discussed. It is desirable if the features of CSS are provided: specification literally or via an external document, for a whole document or within some portion of it, incrementally or all at once, applying to all or to certain types of expressions, by the author or the viewer or both. It is not clear if all these features should be defined in one uniform format, as if they were all part of a single "style sheet", or not. Having one format and source has the advantage of simplicity, but the different classes of features have quite different meanings and uses. At least, the flexibility of CSS in being able to combine style sheets from different sources will be required.]

1. The Math Syntax Model: defines the syntax of HTML-Math subexpressions occurring inside individual SGML elements; that is, includes all parameters which affect the tokenization and the formation of subexpressions from the HTML-Math input characters occuring in one SGML element. This includes:
   • [character set??? See discussion in "Character Set" document.]
   • character parsing attributes;
   • the set of operator tokens;
   • operator forms (infix/prefix/postfix), precedences, associativities, and interpretation as grouping forms (such as left and right parentheses);
   • [perhaps:] rules for formation of number literals and identifiers.

   The Syntax Model will usually be specified entirely by the author, since it would make little sense for a viewer to modify the parsing of an expression. [Whether it makes sense to *prohibit* viewer modifications of the Syntax Model should be discussed. I would propose that it doesn't, since although I can't see why anyone would want to do it, I also can't see a good reason to ever prohibit the viewer from changing anything -- after all, how their browser works is ultimately their business, and nothing prevents them from writing their own browser.]

2. Macro expansion rules: parametrized rewrite rules which describe how to render certain forms of subexpressions by translating them into other forms. [How general these are remains to be discussed.]

   Both authors and viewers will often specify macros, either by defining them directly, or by reference to other documents which define them. [The details of conflict resolution between these remain to be discussed. In particular, it's not clear if the CSS preference for author specificied styles is appropriate in this case.]

   Typical purposes for author definition and use of macros include:

   • Saving typing or document space, by abbreviating commonly used forms;
   • Making it easy to change every instance of a certain construct; and perhaps most importantly,
   • Allowing the definition and use of higher-level expression forms, which can be specified to render in the same way as a "lower-level" version (though perhaps in a way customized by the viewer), but which carry semantic meaning (by convention) which might be different from that of the lower-level version (if any).

   Typical purposes for viewer (re)definition of macros include:

   • Viewing certain constructs in different ways than anticipated by the author;
   • Making selected semantic distinctions visible;
   • Making use of nonstandard viewing media not anticipated by the author.

   These abilities can be of particular importance for viewers with some sensory disability, but they can also be quite useful to almost anyone.

   The details of HTML-Math macros are discussed in the "Macro processing" document.

3. Math Rendering Style Sheet: defines various aspects of rendering style which affect the size and appearance of individual symbols, and the precise spacing used between symbols. [Not to imply that the precise spacing can be specified in general -- this remains to be discussed -- but rather, that whatever it is, it may be *affected* by these rules.]

   The attributes that can be affected include all attributes of text, and others which are specific to HTML-Math. In many cases, these attributes are SGML attributes on various SGML elements defined by HTML-Math.

   [This part will almost certainly be an application of CSS. Nevertheless, the details remain to be analyzed and discussed.]

(end of "Extensibility")