Re: Exploring new vocabularies for HTML

David Carlisle wrote:
>> making the MathML roughly a factor of 3.5 more verbose than the
>> IteX. This is not a trivial  difference.
> 
> Not trivial, but manageable.

That may vary from person to person. I found it to be unmanageable and 
so gave up on trying to use MathML directly.

>>  LaTeX-based workflow, and all of whom use emacs as their primary LaTeX editor) 
>> to see how many people knew the keyboard shortcut for "Close Environment" in 
>> LaTeX.
> 
> emacs like many tools has far more features than any individual can ever
> use fluemtly, you remember the the ones you need. I've typed a lot of latex
> and a lot of xml in emacs, and let's just say that you are rather more
> likely to remember how to get auto-closing assistance in xml than in
> TeX.

That might be true, but it's not clear to me that most authors would 
stick with the format long enough to look up and learn the convenient 
shortcuts if their initial reaction is that it's really hard to use.

> But it's not all bad, emacs (or any editor) has a lot more information in the 
> xml case: So while in latex if you get the nesting wrong, you typically
> don't find out till TeX gets lost processing your document. 

This sounds remarkably like arguing that statically typed programming 
languages are easier to author than dynamically typed ones because all 
the boilerplate information you have to enter makes it easier to program 
an IDE.

> In xml if
> you get it wrong you instantly get a big red underline and your knuckles
> rapped by James Clark.

Yeah, if you set up an XML-optimized environment, you can reduce the 
pain a little. But that's not trivial for everyone to do (e.g. Fedora 8 
doesn't seem to include nxml-mode by default), other editors don't have 
such good XML support. For example entering MathML directly into a HTML 
textarea fo use in a blog comment would be extremely tedious, to the 
point that it would be unreasonable to expect anyone to do it.

Even with the best tools, it's hard to get around the fact that entering 
MathML by hand is more tedious and error-prone than entering TeX-derived 
formats, primarily because you have to write an awful lot of boilerplate 
information that the computer should be able to infer almost all of the 
time. Ironically the fact that this boilerplate drives the need to use 
an equation editor to generate the boiler plate is strong evidence that 
MathML could have a serialization with much less boilerplate and have 
the computer perform the inference when reading an equation rather than 
when writing one.

>> but it does suggest that expecting editor features to fix language
>> deficiencies isn't going to work in practice. 
> 
> That I agree with. It is perfectly correct to be wary of claims that
> people will provide tools to hide language mis-features. But first we
> have to agree on which are the good features and which are the bad.


> TeX syntax works best when used by TeX, there are some attempts at
> TeX->xxx conversions, but basically they all suffer by various degrees
> from the strangeness of using a language designed for the TeX execution
> model in another context. No other system ever implemented a reliable
> import of TeX.

To be clear, whilst I think that the ability to transition knowledge and 
content for TeX-based publishing to Math-on-the-web is crucial, I am not 
suggesting that we try to define a generic TeX-MathML converter. What I 
would really like is a "MathML compact" syntax that looks something like 
standard LaTeX, such that the learning curve for authors is as shallow 
as possible, whilst allowing an unambigious mapping to the MathML DOM model.

> By agreeing on a common syntax notation and explictly
> marked parse tree, MathML on the other hand has gained far wider support
> in a far wider range of systems, CA systems, browsers, word processors,
> even TeX.

Crucially, though, far less support amongst authors. Part of this no 
doubt stems from the difficulties associated with XHTML and the lack of 
support in UAs. However I think you are critically underestimating the 
extent to which MathML itself is to blame for the lack of MathML content.

> MathML syntax has proved a great success as a common format for 
> a wide variety of systems. 
> I think those people that are claiming it
> should change need to offer more proof than just initial gut reaction to
> the amount of element markup. Whenever you look at a different language,
> human or computer, it always looks insanely complicated intitally.

I don't know what I can offer beyond my experience as a would-be MathML 
author. Can you suggest an achievable way to do a more thorough 
investigation of the complexity of MathML to end users?

-- 
"Eternity's a terrible thought. I mean, where's it all going to end?"
  -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Received on Monday, 31 March 2008 21:03:57 UTC