Re: comments re draft version 2.0

You are raising good points and 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 is the
use of

  <elementname/>

versus

  <csymbol definitionURL="..."> presentation </csymbol>

Emphasis has been on ensuring there is a mechanism to
allow the author to define their notation when existing
notation proves inadequate -- something that must
happen.

One of the purposes of this review is to gauge how the
needs of the  target user community are being met and
comments such as yours help immensely.

Of the examples you have raised, I suspect there
may be pretty wide support for direct support of
BigOh, LittleOh,  floor and  ceiling while the others may
infrequent enough to be  handled by the extension
mechanism.

Thoughts?  Are there any other ommissions that
stand out for you?

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:31:44 UTC