[SCL] XML syntax options

Tue Mar 2 01:32:03 CST 2004

Pat Hayes wrote:
 >John Sowa wrote:
>>Murray,
>>
>>I think that we agree on what XML and MathML are,
>>but we are using the word "semantics" differently.
>>
>>The excerpt you quoted says exactly what I said:
>>MathML has no semantics -- i.e., it knows nothing
>>about the meaning of any mathematical expression.
>>The only thing it can do is specify the syntax:
> 
> Well, not exactly. MathML has 2 kinds of markup. The stuff I used was 
> the 'content markup' and that indeed does have an (informally 
> expressed, but adequate) intended semantics which corresponds 
> reasonably well to SCL semantics. 

In the world of definitions, "reasonably well" is not the same as
"identical". If somebody were to have the definitions of MathML and
SCL in front of them, if there are differences, we shouldn't use
MathML. More below on this.

> In particular it has all the 
> logical connectives and the quantifiers, with their usual meanings 
> specified. It uses a very generic 'apply' notion in what is I guess a 
> standard approach to mathematical notation as consisting mostly of 
> applications of operators to arguments, but that is quite consistent 
> with a conventional logical semantics. It handles bound variables 
> quite well.
> 
> One can argue that SCL ought to have markup which explicitly 
> indicates the SCL basic syntactic categories, eg atoms versus terms 
> and so on, so that there is no need for a parser to do this from 
> context: after all, if you have to parse it, it hardly seems worth 
> using XML in the first place. This is the only argument I can find to 
> make against the use of MathML that seems convincing.
> 
> Murray (and Tanel, if Tanel is still with us): what is the purpose of 
> using properties rather than child elements to indicate connectives 
> and quantifiers? This seems arbitrary to me and somewhat unnatural, 
> but I may be missing some significant XML advantage or subtlety.

I tried to make this clear in my last message (at some length). There's
a number of reasons:

    1. being able to use URIs that are declared as such in the DTD.
       You can declare attribute content and constrain it better
       than element content, esp. since we'd have what's called
       "mixed content", which mixes elements and character data.
       Being able to use URIs that are to a processor
       unambiguously URIs (as opposed to text that just might be
       a URI), is a real benefit.
    2. saving enormously on the number of elements and the complexity
       of the language
    3. the language is a lot more extensible (you don't need to add
       an element to add a new predicate, which takes an act of god,
       you just change the attribute content). This is the difference
       between users creating content and creating markup. You don't
       want them creating markup, as it won't be understood. You'd
       have a million different variant DTDs/schemas floating around.

>> > The intent of the content markup in Mathematical
>>> Markup Language is to provide an explicit encoding
>>> of the _underlying_mathematical_structure of an
>>> expression, rather than any particular rendering
>>> for the expression.
>>
>>Nota bene:  structure = syntax, not semantics.
>>
>>
>>> My point in this is that we *can* use MathML if our
>>> definitions of the things we'd use in MathML are
>>> defined identically, otherwise we can't...
>>
>>As I said before, they don't specify what any
>>expression means -- i.e., the conditions for a
>>statement to be true or false or the value of
>>an expression, such as 2+2.
> 
> 
> They don't give a model theory, but they give reasonably exact 
> mathematical descriptions which I think are adequate to convey most 
> of the intended content of SCL.  Substituting 4 for 2+2 is explictly 
> given as one possible way to handle MathML content markup, by the 
> way..
> 
> I guess my own feeling is that since MathML exists and is an accepted 
> standard, and since it provides for almost all of SCL syntax, why not 
> just use it? That is, I think we would need a positive reason NOT to 
> use it if we decide not to: the onus is on any alternative proposal 
> to explain what significant advantages accrue from using it rather 
> than using an existing standard that seems adequate and has almost 
> exactly the same motivation as SCL has.

I think you'd be making a terrible mistake to adopt it without labeling
it as such. If you don't adopt it, change its name and make it *somehow*
clear in the markup (discernable to a processor) that the SCL version of
MathML is not MathML, that the definitions for the markup are not the
same. SCL's definitions of those MathML elements would not be the same
as MathML's:

    F. Content Element Definitions
    http://www.w3.org/1999/07/REC-MathML-19990707/appendixF.html

It would be considered wrong by anyone with experience in the markup
community to have two applications with different semantics using the
same markup language. How would a computer know which is which? Now,
we could use MathML's markup (or some subset of it) and change the
XML Namespace to be "http://purl.org/xcl/1.0/" or some such thing. I
got the PURL for that reason (i.e., to have a namespace). It would
just be wrong to label "SCL-in-MathML" as "MathML". If you think MathML
would work, then use it, but relabel it and provide the redefinitions
for the MathML elements. If we don't use all of the MathML elements,
we'd need to remove them from the DTD.

If you really want to go this direction, I'm even willing to edit the
DTD for you. I just think that we're talking about two different
languages. The MathML version won't have any linking, won't be extensible,
and would require new elements for any new predicates, quantifiers, etc.
that aren't in MathML, or whenever a user needed one that wasn't there
(i.e., not extensible). But if there's no requirement for linking, no
requirement for extensibility, then a relabeled MathML would work fine.
I can send you a list of MathML elements, you mark which aren't in SCL,
and I edit out those elements. Relatively simple.

If you relabeled MathML there'd be nothing inherently wrong with
using it. But I don't think it solves what *I* think are the requirements
for this language, which is to be web-ified and extensible. You won't
get that with MathML. But since nobody has bothered to publicly state the
requirements for XCL, there's no metric and no way of knowing whether
MathML will actually suit. It may be that there are a number of
different XML syntaxes for SCL, one being a labeled variant of MathML,
another being a webified, extensible markup language version. They
would have very different uses, and very different appeals. In my
original XCL proposal I had two different languages that were very
related to each other syntactically (which I called Level 1 and 2,
if I remember correctly).

Murray

P.S. One of the things I've noted is that due to its age, MathML does
not include an XML Namespace identifier. This means that processors
that come across MathML won't be able to differentiate it from an
XCL variant (since we can assume that those processors aren't
expecting to use XML Namespaces as the differentiating factor). So
some processors may ignore the XCL-ness of the markup and treat it
as MathML.

Also, as noted here:

     http://www.w3.org/1999/07/REC-MathML-19990707/chapter1.html#sec1.3.2

the means of integrating MathML with HTML weren't known at the time
it was developed and published. As a former member of the W3C HTML WG,
I can say that there isn't a safe and reliable way of integrating
MathML 1.0 with XHTML within browsers, neither from the markup, the
XML, nor the browser standpoint. Now, no markup language for SCL is
going to seamlessly integrate with XHTML either. The W3C has not really
provided a solution for this yet (after how many years?!). Part of the
problem is that there's little cooperation from the browser vendors,
part is that the HTML WG doesn't have enough power within the W3C to
push for a W3C-wide solution. I also don't think they've got the
expertise. It's a mess.
......................................................................
Murray Altheim                    http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .

    "Ours is a dangerous time with two relatively new threats,
     both of them exacerbated by the Iraq invasion and this
     administration's policies. One is the threat of future
     terrorism by Osama and al Qaeda. The other is the threat
     to our freedoms and our constitutional republic. These
     are dangers that were never faced before in my lifetime."
                                               -- Daniel Ellsberg
     http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2004/02/29/CMG3R50LHE5.DTL