From: Stan Devitt <jsdevitt@radicalflow.com>

Date: Tue, 11 Apr 2000 00:58:39 -0400

Message-ID: <004b01bfa372$99d90880$6561a8c0@devitt.local>

To: "David Eppstein" <eppstein@ics.uci.edu>, <www-math@w3.org>

Date: Tue, 11 Apr 2000 00:58:39 -0400

Message-ID: <004b01bfa372$99d90880$6561a8c0@devitt.local>

To: "David Eppstein" <eppstein@ics.uci.edu>, <www-math@w3.org>

You are raising good points and I know the working group is listening closely. In my responses, I have tried to raise some of the reasoning that is behind some of the choices that have been made within the group. There are some tough calls on where to cut off for pre-defined elements. Wherever the cut off is, it will leave something out and this is why support for user defined extensions is so important. The primary difference between built-in and user defined has been reduced to <elementname/> versus <csymbol definitionURL="..."> presentation </csymbol> The structure of the latter is dictated largely by the XML model being used and the need to provide a mechanism for the author to identify both a definition and a presentation. In both cases, more complicated presentations (such as needed floor and ceiling) are handled via additional style transformations or semantic pairings. The current review needs to identify how well the needs of the target user community are being met and comments such as yours help immensely. Of the examples you have raised, and taking into account the target audience of roughly K through 13 (first year university), I personally suspect there may be pretty wide support for direct support of BigOh, LittleOh, floor and ceiling while the other examples you raise may infrequent enough to be handled by the extension mechanism. The move to discussion of algorithm bounds earlier in computing courses would drive such a need. Reactions anyone? Stan Devitt ----- Original Message ----- From: David Eppstein <eppstein@ics.uci.edu> To: <www-math@w3.org> Sent: Monday, April 10, 2000 9:28 PM Subject: Re: comments re draft version 2.0 > Stan Devitt <jsdevitt@radicalflow.com> writes: > > O(x) could be written. > > <apply><csymbol definitionURL="CRCStandardMath_30" > > encoding="text">O</csymbol> > > <ci>x</ci> > > <apply> > ... > > <apply><csymbol definitionURL="...">floor</csymbol> ...</apply> > [plus a recommendation to use mixed content-presentation style so the > floor actually looks right] > > So, is there a good rationale for including basic freshman/sophomore > statistics notation like <sdev/> while forcing equally basic > freshman/sophomore discrete math and computer science notation like O, > floor to go through these unstandardized and unpretty convolutions? > > Re my third point, chains of inequalities (or of subset relations, or > other partial orders), the suggestion was to represent it as a > conjunction of binary relations. I respect the point that it may be > difficult to come up with a correct definition of a valid chain (although > it seems simple enough to me to require all relations in a chain to be > equality, inequality, and strict inequality from a common partial order), > but a chain is semantically different from a conjunction, in that it has > the additional requirement that the rhs of one inequality be identical to > the lhs of the next, so that one can automatically apply transitivity to > deduce a relation between any two members of the chain. I thought the > purpose of content style over presentation style was to preserve useful > semantic information? > -- > David Eppstein UC Irvine Dept. of Information & Computer Science > eppstein@ics.uci.edu http://www.ics.uci.edu/~eppstein/ >Received on Tuesday, 11 April 2000 00:56:09 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Saturday, 20 February 2010 06:12:49 GMT
*