How to connect educational programs to the Web
Jocelyn Ireson-Paine

The Web as an educational tool

• I shall talk about how programs can be connected to the Web for educational use. The examples in this talk come from a project done with the London-based Institute for Fiscal Studies (IFS).

• The IFS was set up to improve the public understanding of finance, by carrying out impartial analyses of Government financial policies and publishing the results. Its work includes analysing the effects of changes in taxes on people - these include "direct taxes" or taxes on earnings (e.g. Income Tax), and "indirect taxes" or taxes on expenditure (e.g. Value Added Tax).

• One way to publicise such things is by putting research papers on the Web. The IFS has had a Web site for this since late 1994. The Web is already very valuable, just as a source of research reports and other static files.

• This is valuable in itself. But we can go further. Why not connect our analytical programs to the Web, so that people can run them for themselves? Then they can try out analyses that may not be in our publications.

• Each year, just after the annual Budget [when the UK Government announces taxes and other financial plans for the next year], the IFS uses an economic modelling (i.e. simulation or prediction) program to predict the effect of the Budget's tax changes on a small set of example families. It gives the results to the BBC [the UK television organisation], who publish them on the News. In 1995, we started a project to connect the program that does this to the Web, so that anyone with Web access could run it. We started by doing this on the IFS site. Then in 1998, before this year's Budget, the BBC asked us to make the same program available on their News Online site.

• The project resulted in two Web-based programs. Be Your Own Chancellor lets its user act as Chancellor of the Exchequer [the politician who is in charge of finance and who announces financial plans during the Budget]. The user can change taxes and other financial parameters, and the program will predict the effect on a range of sample families. Be Your Own Chancellor is here at the BBC site and here at the IFS site.

  Budget 9x lets the user enter his or her own financial details, i.e. income and expenditure. It will then calculate how the last Budget would affect these. Budget 9x is here at the BBC site and here at the IFS site.

• These use "server-side" processing. The user types data into a form, and this is sent to the Web server, which calculates results and sends them back as HTML.

• What are the advantages for education? The educator only needs to write the program once and connect it to a Web server. Anyone with a browser can then run it - no problems with porting to different machines. (Load on the server might be a problem with some applications, but was not for us.)

• Unfortunately, there can be legal problems that make such work less useful than it should be. In our case, for Be Your Own Chancellor, using a small sample of families gives a very incomplete picture of the effects on the entire population. The IFS has data available for about 7000 families: this larger sample would give a much better picture. However, public use of the data is banned - partly to avoid people identifying the families involved, but perhaps also because the research council who own the data want to retain its use for possible commercialisation. Sometimes, copyright can be a problem - e.g., when you publish a paper or book, you normally need to transfer copyright to the publisher. This removes your right to put the publication on the Web. This happened with a forthcoming book on CafeOBJ (see end of talk).

• Note that the Web's hypertext nature is useful. Fields of forms, etc., can be linked to help text that tells the user more about what he or she needs to enter. Similarly, output pages can contain links to explanations of the results. In Be Your Own Chancellor, the output page contains a link to help text on the limitations of the model.

How such programs work

• Web programmers distinguish "client-side" and "server-side" processing. In server-side processing, the Web browser asks the server to run a program. The server does, and returns the results. In client-side processing, the browser asks the server to send it the program, and then runs it locally. Java applets and JavaScript work like this. We use server-side processing.

• How does data reach the server? Let's start with static pages. When the browser requests a Web page, it sends a URL to the Internet, e.g.

  http://www.ifs.org.uk/index.htm
  

  The Internet uses the address part of the URL to find the right server, and routes the rest of the URL to it. It arrives as one line:

  GET index.htm HTTP/1.0
  

  GET is one of several possible HTTP (Web protocol) commands - it tells the server to send back HTML corresponding to the name that follows. HTTP/1.0 is just an identifier telling the server which HTTP protocol the browser is using. Version 1.0 is the most common, but there are others.

• The HTML below defines a form with two input fields and a Submit button, like this:

  First number: Second number:

  <FORM ACTION=calculate METHOD=GET>
  First number:  <INPUT TYPE=TEXT NAME=a VALUE=0><BR>
  Second number: <INPUT TYPE=TEXT NAME=b VALUE=0><BR>
  <INPUT TYPE=SUBMIT VALUE="Add the numbers">
  </FORM>
  

  When the user submits this form, the server will receive the following request (if her or she has entered the values 3 and 4 respectively):

  GET calculate?a=3&b=4 HTTP/1.0
  

  The browser sends the name after ACTION as the new URL, and follows it by a ? and the data from the fields as a sequence of name=value pairs separated by & characters.

• The server can recognise from the name calculate that the request is for a program to be run. It could then extract the data following the ?, and pass it to the program by writing it to a temporary file which the program must read. Or, if there isn't much data, via the program's command line.

• The program must write its results as HTML, naturally. This is no problem, and provides the author with a cconvenient way to format the output. How do these results get back to the browser? On many servers, for example Apache, anything the program writes to standard output will automatically be sent to the browser. On others, such as OS/2's GoServe, the program has to write its results to another temporary file, and the server then sends that back.

• (For completeness, note that there is another way to send data from a form, the so-called "POST method". The principle is similar, and information can be found in any document describing the "Common Gateway Interface" or CGI, for example here.)

• The point of this section has been to show that it's easy to connect existing non-Webbed programs to the Web.

Graph-plotting on the Web

• Be Your Own Chancellor has a "budget constraint" option. The user can ask for a graph of gross income against net income. This is a useful tool in understanding how workers trade-off between using their time for leisure and using it to earn money.

• To generate the graph, the model wrote the data points into a temporary file, as well as writing the output page. The server then called Gnuplot, a public-domain plotting program, to generate the graph. The graph was plotted into a temporary file, and the model included in its output page a reference to that file.

Session-type applications

• The technique above is OK for "single-shot" programs, where the user submits data, gets the results of a computation, and finishes. But it does not work for "session-type" applications.

• These are applications where the user interacts over a series of transactions, and where the state of the user's session must be preserved between transactions. A common example is shopping services, where the user starts with an empty order ("shopping basket") and can add or delete things from it at each transaction. One of the best-known is Amazon's interactive bookshop.

• This is difficult to program, since the Web protocol gives no natural way to distinguish different sessions. Every time the user requests a page, e.g. by submitting a form, the browser makes a new connection with the server, and closes it after receiving the results. It does not automatically send any user identification. So if John and Peter both order a new book from Amazon, how can Amazon's server tell which request is from John and which from Peter?

• The standard solution is to embed, in every URL that refers to the state of the session, a unique session identifier. Take Amazon as an example, and suppose their entry page looks like this:

  Welcome to Amazon Add a book to your order. View your order Pay for your order

  This page contains three links, all of which point at pages whose content will depend on the session they belong to.

  The server would allocate the user a unique session identifier when he or she starts. It would then embed this in every URL, for example:

  <B>Welcome to Amazon</B>
  <P>
  <UL>
  <LI><A HREF="http://www.amazon.com/add/474052z">Add a book to your order</A>.
  <LI><A HREF="http://www.amazon.com/view/474052z">View your order</A>
  <LI><A HREF="http://www.amazon.com/pay/474052z">Pay for your order</A>
  </UL>
  

  Then if the user clicks on any of these links, the server will receive the identifier, and can use it to find the state of the relevant session. This could be stored in a database, for example.

• Note that with this technique, every time the server receives the URL for the entry page, it will generate a new one with a different identifier. This means that if the user tries returning to their original entry page, the server must (in order to be consistent) generate a new one. If the user then followed the links in this page, he or she would get the state of the new session identified by the identifier in these links.

  To prevent this, we can use "redirection commands". When the server generates the entry page, it does not immediately send it back. Instead, it sends the browser a command telling it to request another URL, for example

  http://www.amazon.com/new/474052z
  

  The server then receives a request for this second URL, and then sends back the entry page. If the user then goes back to the entry page later, the server will recognise the new/474052z in the request, and know it must send back the same page, rather than generating a new one with a different identifier.

Web-authoring tools

• Embedding state identifiers in URLs like this, it is necessary to generate dynamically any page with a link or form that refers to the state of the user's session. This means that the Web-page author has to write programs to generate these pages, which is more work and distracts attention from their content. Numerous tools have been developed to make the task easier.

• Some of these tools are libraries, e.g. in Perl (a Unix string-processing language often used for writing Web server scripts and many other systems-programming tasks).

• Others define a new programming language for writing interactive pages. Usually, this looks like an extended version of HTM. For one example, see Universal Access Inc's site. Meta-HTML is one authoring tool: others include Sun's Web Page Compiler, Allaire's Cold Fusion, Apple's Web Objects and htmlscript Corporation's htmlscript.

• These tools can either be interpreters or compilers. Interpreters have a program attached to the server that examines the source of the Web page being sent back, and executes some commands within it.

  Server-side includes are a simple example of this. They are implemented by many servers, which recognise pseudo-HTML commands such as (for example) <!--#include file="address.html"--> to include the contents of the named file at that point in the Web page. This is useful for inserting pieces of HTML that will be the same between many pages, such as company logos.

• In contrast to interpreters, compilers compile the Web page beforehand into some kind of intermediate code, which is run by a program attached to the server. Sun's Web Page Compiler compiles into Java.

• My Web-O-Matic is an authoring tool which also compiles into Java. It treats Web pages as composed of objects such as text fields. It was developed for some more ambitious applications at the IFS (not the ones mentioned earlier), where it might be necessary to retain the state of a large number of data-entry forms throughout a session. Its semantics is based on category theory and sheaves. While here, I am looking at the use of the algebraic specification language CafeOBJ as a way to specify its semantics.

Further information

[ Jocelyn Ireson-Paine's Home Page | Departamento de Informática da Universidade do Minho]