From: Stan Devitt <jsdevitt@stratumtek.com>

Date: Thu, 8 Aug 2002 17:24:50 -0400

Message-Id: <200208082124.LUG06279@vmms6.verisignmail.com>

To: Herman Schenck <herman@velosel.com>

Cc: "'www-math@w3.org'" <www-math@w3.org>

Date: Thu, 8 Aug 2002 17:24:50 -0400

Message-Id: <200208082124.LUG06279@vmms6.verisignmail.com>

To: Herman Schenck <herman@velosel.com>

Cc: "'www-math@w3.org'" <www-math@w3.org>

There was a conscious decision in the working group to leave string operations to the "extension" mechanism. In particular we also left out programming constructs such as assignments, loops and conditionals. A main early goal was to keep the recommendation focused on the passive representation of basic algebraic constructs. There are perfectly good string algebras, of course. Your question implicitly raises the question of whether the content of <ci>abc</ci> is treated as atomic or not? Yes and No answers are both acceptable. If the ci elements are regarded as the alphabet symbols then concat( "a" , "b" , "c" ) could be written <apply><times definitionURL="stringop" /> <ci>a</ci> <ci>b</ci> <ci>c</ci> </apply> Alternatively, we could view the ci tags like string delimiters (with extra restrictions on the content of the ci) and then concat( "abc" , "def" ) could be written. <apply> <csymbol definitionURL="concat"/> <ci>abc</ci> <ci>def</ci> </apply> and substring( "abc" , 0 , 2 ) // "ab" would be <apply> <csymbol definitionURL="substring"/> <ci>abc</ci> <cn>0</cn> <cn>2</cn> </apply> Ideally, the definitionURL's would point to where such design decisions were documented. Both examples are valid MathML. Stan Devitt ---- Original message ---- >Date: Thu, 8 Aug 2002 13:09:20 -0700 >From: Herman Schenck <herman@velosel.com> >Subject: text functions in MathML >To: "'www-math@w3.org'" <www-math@w3.org> > > >I have been looking to extend MathML to handle text functions like >"substring" and "concat". > >Is there any accepted way of doing this? > >One problem I see is that string constants do not have their own tag. > >Thanks, > >-herman >Received on Thursday, 8 August 2002 17:24:52 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:27:32 UTC
*