Re: The interpretation of script

> Not to argue this point too strenuously, but I think the time is fast 
> approaching. One JavaScript reaches a level of performance where it 
> can in fact be used as a virtual machine, it will be. XQuery is the 
> most obvious one to me in that regard because of XQIB but I know there 
> are similar efforts at developing a JavaScript shim for Python 
> underway now (something I believe would have immediate appeal to 
> Google, given the level of in-house python development they do).
>
>

Let's look at another of my favourites - MusicXML. Like SVG, this can be 
viewed as passive data, or as instructions to display a musical score on 
the screen and/or render the score aurally. There's a community that 
wants to do this in the browser - a small community, perhaps only a 
million people, not enough to be interesting to the browser vendors, but 
quite possibly large enough to sustain the necessary investment in 
software to make it happen.

In the short term, the solution to this requirement is to write a "shim" 
in Javascript or XSLT, the only two programming languages which the 
browsers support. But some bright spark is going to decide at some stage 
that this is too sluggish (you can't wait for the screen to refresh if 
you're in the middle of a performance at the Carnegie Hall), and they 
are going to write a fork of Firefox that has native MusicXML support, 
and a million musicians are going to start using this as their default 
browser.

At that point anyone delivering MusicXML content is going to have to 
worry about delivering it to two kinds of browser, those with native 
MusicXML support, and those that handle it via a shim. How do we see 
this being done? Or are we simply going to say "this is more than 12 
months away, we'll sort something out when the time comes?"

Michael Kay
Saxonica

Received on Tuesday, 18 January 2011 17:18:35 UTC