[SCL] XML syntax options

Pat Hayes phayes at ihmc.us
Fri Feb 27 18:15:40 CST 2004


Ive been trying to figure out what is the best way to handle a 
structured XML syntax for SCL.

Currently we have two main contenders, as far as I can see, for the 
overall 'style'. Murray, following Tanel, suggests having generic 
tags corresponding to the syntax classes with the actual names as 
properties. The boy-kissed-girl example

(forall (x) (implies (Boy x) (exists (y) (and (Girl y)(Kissed x y) )) ))

looks like this:

<quant name="forall" variable="x" >
    <conn name="implies" >
      <pred name="Boy" >
      <term name="x" / >
      </pred>
      <quant name="exists" variable="y" >
         <conn name="and" >
              <pred name="Girl">
               <term name="y" />
              </pred>
               <pred name=" Kissed">
               <term name="x" />
               <term name="y" />
              </pred>
         </conn>
       </quant>
    </conn>
</quant>

We can argue over details, such as do we really want to allow for 
other kinds of quantifier, but first consider an entirely different 
style, which is the way this would look in MathML:

<apply>
   <forall/>
   <bvar> <ci>x</ci></bvar>
   <apply><implies/>
      <apply>
      <ci>Boy</ci>
      <ci>x</ci>
      </apply>
      <apply>
         <exists/>
         <bvar> <ci>y</ci></bvar>
         <apply><and/>
            <apply>
               <ci>Girl</ci>
               <ci>y</ci>
            </apply>
            <apply>
               <ci>Kissed</ci>
               <ci>x</ci>
               <ci>y</ci>
            </apply>
          </apply>
     </apply>
    </apply>
</apply>

This uses child elements rather than element properties to encode 
every part of the structure, including things like bound variables. 
It is longer-winded than the T-M style, but it has several 
advantages. First, it conforms to an existing standard which is 
endorsed by the AMS and the W3C and others, and there are (I gather) 
already tools out there to manipulate it, render it, and so on, and 
newer-generation browsers will likely render it automatically in a 
readable way (The MathML spec defines default renderings for all the 
logical primitives and whole lot more.) Second, MathML allows for 
'display markup' to be added so as to force the SCL to be rendered in 
a particular graphic style. Having the same structural description 
independent of the rendering strikes me as an elegant way to handle 
'abstract syntax'.

The disadvantages are that the MathML 'primitives' such as apply and 
ci (= identifier) are not particularly informative for SCL, so an SCL 
engine will still need to effectively parse this. However, MathML 
allows for user-defined entities so we could follow their basic style 
with our own special tags for, say, atoms and terms and seqvars. 
MathML provides quantifiers (with restrictions), connectives, 
numerals and the notion of application. It doesnt provide the 
term/atom distinction, datatyping or anything like a seqvar notion, 
and its way of doing cross-linking in documents is clunky, to say the 
least.

So, any opinions? Should we conform to MathML, or go it alone? Or do 
both, ie give an XML syntax but explicitly allow the use of MathML?

Pat

PS. BTW, neither of these is human-readable, of course. Our spec 
should also allow things like this:

<scltext dialect="scl-core">
(forall (x) (implies (Boy x) (exists (y) (and (Girl y)(Kissed x y) )) ))
</scltext>

so that SCL text in any dialect can be 'piped' through XML without 
significant change. MathML already has facilities for including 
expressions written using other conventions, so it could handle this 
kind of thing also, so this is independent of the above decision.


-- 
---------------------------------------------------------------------
IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes at ihmc.us       http://www.ihmc.us/users/phayes




More information about the SCL mailing list