For a zipped version of this paper please click here.

XML and the Law

A gentle voyage round XML, electronic case files and electronic filing

by Roger Horne

  Introduction
  XML
  Electronic Case Files
  Electronic Filing
  Conclusion
  

Introduction

1.   In January 2001 Court Service published, as part of the Courts and Tribunals Modernisation Programme, a Paper called "Modernising the Civil and Family Courts". In May 2002 it published a survey of the responses to that Paper (which does not appear to be available yet in electronic format) and a further Paper setting out its conclusions (available as a PDF file here). On 23rd May 2002 Lord Justice Brooke gave a speech at the University of Hertfordshire, a transcript of which is available here. These documents all refer to the benefits to be found as a result of the introduction of an Electronic File for each case; the Court Service survey also referred to the use of XML in the law. The Paper which you are now reading, which is a substantially revised version of a talk I gave, also on 23rd May 2002, to the Society for Computers and Law, Internet Interest Group, is intended to be a gentle and (so far as is possible) non-technical guide to XML, Electronic Files, and Electronic Filing. (The last two are not the same thing.)
2.   What I intend to do is to explain my views on the merits of textual markup in general and then to try to show how one version of such markup, XML, could be used in relation to one specialised area of the law, ie, civil litigation. (There are many other areas in which is would be equally useful and a lot of research is being undertaken into this.)
3.   First, a few basic points. Although XML is described as a layout or markup language, it does not actually do anything. There is no computer program called XML: it is not a word processor. The question: Why should I use XML when I am completely happy with Word?" is meaningless. An XML document simply exists---it does not do anything. It can be written by hand in a text editor, or it can be written by a full-blown Word Processor: existing word processors such as Word™ and Word Perfect™ will soon be able to produce XML files and Sun's recently-released StarOffice™ uses XML as its main output format. In addition there are already a number of specialised XML Word Processors such as Morphon™, Spy™ and Epic™.
4.   That question would be valid if it was rephrased as: "Why should I tell my word processor to output files in XML when I am quite happy with the way that it prints and stores them at the moment?". To answer that we need to go back to the basics of markup languages, or rather to the difference between a word processed file and a file marked up in XML (or in any other markup language---and there are lots of them).
5.   If you look at a word processor's output file in a text editor, or use the reveal codes feature in Word Perfect, you will see that the file contains a lot of material other than the text that you have typed. Some of this will be readable and understandable but most of it will not, the reason being that it contains the formatting instructions. So if you have a heading in your document "PARTICULARS OF CLAIM" the output file will contain instructions, in a form which that particular word processor understands, saying something like:
  
(1)   Change to Helvetica at 18 point Bold
(2)   Move 126 internal units (where the units may be points, or fractions of an inch, or some other proprietary measurement) across the page and 7 units down;
(3)   Print the correct letters and spaces;
(4)   Move to the start of the line, move down 20 units, change (back) to Times Roman at 12 point Normal;
6.   If the file that you produce is going to be used on your machine only, and is only going to be used for one purpose only, eg to produce a single printed copy of the document, such as a letter which will be put in the post or DX, this may well be the best way of doing things. But it may not be the sensible way of doing things if you intend to send it electronically to someone else for a number of reasons:
  
(1)   A word processed file is long:
   I wrote a Word file containing "PARTICULARS OF CLAIM", ie 20 characters, in 18 point Bold Times Roman. The file contained nothing else: when saved it contained 3,190 characters. This is a brief extract from it:
  
  

[00][00][00][00][00][00][00][00][00][00][00][00][00][00][00]
[00][00][00][00][00][00][00][00][00][00][00][00][00][00][00]
[00][00][00][00][00][00][00][00][00][00][00][00][00][00][00]
[00][00][00][00][00][00][00][00][00][00][00][00][00]PARTICULARS
OF CLAIM[0d]ê[00]¤ƒ.¥ÇA¦ [05]§°[04]œ [05] [05]…Ô[00][00][01]
[08][00][00][01]€[00][00][01][00]Ğ[02][00][00][00][00][01][08]
[00][00][01]€[00][00][01][00]Ğ[02][00][00][00][00][01][08][00]
   (The characters in square brackets are non-printing control characters.)
(2)   The Recipient may use a different word processor, (or an earlier version of the same word processor), which is incapable of reading the file
(3)   The Recipient may use a different printer, different fonts, different sized paper. The Recipient may be short sighted and or suffer some other form of disability which requires that the document be "read" to him by a computer program or displayed in a huge font or in braille. None of those will necessarily prevent the word-processed file being used, but a large amount of the original formatting information will simply be discarded or replaced and so sending it will have been a waste of time.
7.   Going to the other extreme, it would be possible to send out the document in telegraphic format, ie as a long stream of text, but again most Recipients would find this pretty difficult to use, since it would contain no indication of how the document was to be formatted. But even a telegram or telex does contain some formatting instructions:
  
  

HAVENT HEARD FROM YOU IN AGES STOP LOVE YOUR
LATEST SHOW STOP THIS NO PHONE STUFF IS FOR BIRDS
LIKE YOU STOP ONCE SHOUTED UP FROM STREET ONLY

RAIN AND YOUR ASSISTANT ANSWERED STOP DO YOU
STILL SLEEP LATE STOP DOES YOUR PAINT STILL COVER
DOORS STOP FOUND A SAMO TAG COPYRIGHT HIGH

ABOVE A STAIR STOP NOT SURE HOW YOU REACHED STOP
YOU ALWAYS WERE A CLIMBER STOP COME DOWN SOME
DAY AND SEE US AGAIN END
   © 2001 by Kevin Young.
From To Repel Ghosts, Zoland Books, Cambridge, Massachusetts.
Reproduced with the kind permission
of the Author and Zoland Books.
8.   Note the use of "STOP" and "END", and of blank lines to indicate new paragraphs (or in this case, new verses). However this is, of course, very basic markup. What using full textual markup in a document can do is to separate the structure of a document and the way that the document/structure is presented to the end user. "PARTICULARS OF CLAIM" is a heading in a pleading. Instead of being marked-up by the Word Processor with full formatting information the phrase could be marked up as:
  <Heading>PARTICULARS OF CLAIM</Heading>
   The markup contains no formatting information: the formatting would be added by the recipient's word processor, or other software on his computer, in whatever way the recipient considered to be appropriate or useful. Another advantage of markup is that it makes it possible to omit redundant information from the document, but I will come back to this.
9.  The first markup language I came across was the typesetting language TeX---I read an article in a magazine and then, during a short spell in hospital many years ago, read The TeXbook by Donald Knuth (the program's author). TeX is used primarily for mathematical typesetting but it is perfectly capable of being used for other purposes. Like an XML file, a file marked up in TeX does nothing in itself. However unlike XML there is also a PD program called TeX which will take a TeX file and process it to produce a file which can be displayed on a screen, printed at any resolution, and so on.
10.  Plain TeX itself only permits text to be marked up in a very limited way. But it is possible to extend it by defining other markup in a way which the TeX program will understand: like XML it is an "extensible" markup language. The best known extended version of TeX is LaTeX which is used primarily for the production of papers to be published in academic journals. I have my own version called LeXTeX which unsurprisingly is intended for the typesetting of legal material; I still use it for almost all of my written work.
11.   TeX markup consists of a backslash, a name and (often) parameters enclosed in squiggly brackets. So, for example, the fact that Mr John Doe is the Defendant in a case could be indicated by marking up his name in the text as \defendant{John Doe}. A Witness Statement (using extremely silly facts) could take the following form:
  
  

\solsref{ABC/1234}          % Solicitors' reference
\colsref{SUEGRA/9876}       % Counsel's reference
\ourclient{1}               % We act for the claimants

\claimant{JOHN SMITH}       % Details of the case
\claimant{ELIZA DOOLITTLE}
\defendant{RICHARD ROE}
\claimno{34567}
\queensbench

\deponent{Albert McTavish Smith}
    \of{The Distillery, Somewhere, Scotland}
    \occupation{Whisky Distiller}

\datesworn{23/5/2002}
\wstatement

\cl \exhibited is a large bottle of whisky.
    It is empty.\xref{bottle}
\cl \exhibited is a glass smelling strongly of
    whisky. My sensitive nose can tell that
    the whisky that was in the glass came from
    the bottle referred to in \pararef{bottle}
    \xref{glass}.
\cl I have seen the glass referred to in
    \pararef{glass} in the possession of the
    Defendant.

\bye
  If I process that file with LeXTeX I get a fully typeset output file: a browser cannot display this file, but images of it can be seen here. Note that all the formatting has been added by the processor: there was no formatting information in the file which I typed in. The LexTeX processor has lined up the names of the parties, added the appropriate headings and endorsements and the name and address of the Solicitors acting for the Claimants, numbered the paragraphs, resolved and added cross-references, and added a statement of truth. TeX has, however, a number of disadvantages as a document exchange format. The main one is, of course, that although many mathematicians use it, very few lawyers do. And it is not an easy language to use.
12.   Another major markup language is SGML. It is an international standard and has been in existence for over 20 years. It is widely used for the marking up of technical documents especially by US Government and Military. More relevantly HMSO have been using it to markup the text of statutes and SIs for over 15 years: I have an Article written in 1986 describing the process. However SGML is extremely complicated and is not suitable for all purposes purposes. It has produced a number of simpler "off shoots", or variants, one of which is HTML---which is the markup language used to produce most pages displayed on the Web.
13.  But HTML goes to the other extreme---it is far to rigid a format to be used by lawyers for the exchange of documents: the markup used in it is fixed and cannot be extended. As a result it would be almost impossible for a typist or a fee earner to produce a Claim Form in HTML: there is no way of specifying that Mr Doe is defendant or that Mr Smith is a claimant. It is possible for a computer program to produce a Claim Form formatted in HTML: see, for example, this contrived and somewhat defective example, but here HTML is being used as an output or display format: the HTML was written by computer program, not an individual.
   
  

XML

14.   A more recent off-shoot from SGML is XML, the "eXtensible Markup Language". As with TeX it is possible to define new markup with XML. Indeed you do not need to specify what the markup means or does if the file is for your own personal use only. So
  
  

  <Old_Riddle>
    <Question>
       Why did the chicken cross the road?
    </Question>
    <Answer>
       To get to the other side.
    </Answer>
  </Old_Riddle>
  is well-formed XML. But by itself it is very little use. A computer receiving it would not know how to display the text since it would not know what the markup meant---if you loaded the file into a browser it will display it like this (which, depending on the browser you are using, is probably as a long line of text):
  
   Why did the chicken cross the road? To get to the other side.
   This may be what the writer intended, but it seems unlikely. An individual reading the file in a text editor could deduce what it was meant to show---it is always possible, although not necessarily simple, for a human to read an XML file since it is written in plain ASCII text. But without further instructions a computer program is likely to be lost.
15.   So it is usual to do two things in relation to XML files that are to be read by more than one person. The first of these is to define the markup and the way that it can be used, ie its grammar, in a separate file, either as a "Document Type Description" (DTD) or as a "Schema". (There are substantial differences between the two, but basically both contain the formal grammar of the document: the latter can impose more detailed control over the way that the grammar is used.) The DTD for the chicken example might say that an <Old_Riddle> should contain a single <Question> followed by a single <Answer> (so that providing alternative answers to a single question, or two questions with a single answer, or a question preceded by an answer, would be incorrect).
16.   The second is to set out the way that the marked up data should be displayed in a stylesheet. In this particular case the stylesheet might say that the question was was be introduced by the word "Question:" in a large blue font and the answer by "Answer:" in a large red font, the text in each case being indented and set in a smaller italic font, and so on:
  
An Old Riddle
   Question:
  Why did the chicken cross the road?

Answer:
  To get to the other side.

   There are two types of stylesheet in common use with XML documents. The first are cascading stylesheets (CSS), which are similar to the ones often used with HTML files (and which could be used to produce the "chicken" style), and the second the more powerful XSL stylesheets which I will describe in more detail later.
17.   In a DTD to be used for pleadings it would be necessary to define markup for a number of different elements including the obvious ones such as "claimant" and "defendant" (and their addresses and other contact details). It would also be necessary to provide markup for the court or division in which the case was to be heard (for example Queens's Bench or Chancery), the case number, the lawyers and their contact details, the types of paragraphs and sub-paragraphs, footnotes, cross-references, links to related cases, restrictions on public access to the document, and so on. Some of these would only need to be used in one particular class of document, that is, the Claim Form and amendments to it: it would not be necessary to specify the telephone number of the Claimants' solicitors in the reply since it would already have appeared in the Claim Form or in a Notice of Change of Solicitors.
18.   It might well be necessary to specify a large number of additional markup elements. An American not-for-profit organisation, LegalXML (to which I will refer later) has just published details of a DTD to be used in relation to "Court Documents" (which in English terms would include Pleadings, Witness Statements, Orders, Judgments and any other documents similar documents, but would not include transcripts). My own view is that many of the markup tags suggested are unnecessary in this jurisdiction, but the document is certainly required reading for anyone contemplating writing a DTD for use with court-related material in this country.
19.   A file containing a simple Claim Form marked up in XML could look like this (where the XML markup is shown in blue for clarity):
  
  

<?xml version="1.0" standalone="no"?>
<!DOCTYPE Pleading SYSTEM "pleading.dtd">

<Pleading>
 <Claim_Form part="7" court="QB" hr="No">
  <Case>
   <Case_Number>HC 987654</Case_Number>
   <Claimant>
    <Name>
     <First_Name>John</First_Name>
     <Last_Name>Smith</Last_Name>
    </Name>
    <Address>
     <Line>The House</Line>
     <Line>The Island</Line>
     <Line>Cornwall</Line>
    </Address>
    <Solicitor>
     <Firm>Sue Grabbitt \& Runne</Firm>
     <Address>
      <Line>1234 Lincoln's Inn Fields</Line>
      <Line>London</Line>
      <PostCode>WC7A 9JJ</PostCode>
     </Address>
     <Reference>GR1-1234</Reference>
    </Solicitor>
   </Claimant>
   <Defendant>
    <Name>
     <First_Name>Richard</First_Name>
     <Last_Name>Rowe</Last_Name>
    </Name>
    <Address>
     <Line>1 Railway Cuttings</Line>
     <Line>Cheam</Line>
    </Address>
   </Defendant>
  </Case>
  <Claim>
   <Facts>
    Damages for the theft of the contents
    of a bottle of rare and valuable whisky.
   </Facts>
   <Damages_Claimed>
    53.42
   </Damages_Claimed>
   <Costs>
    100
   </Costs>
   <Struth>
    <Signatory>
     Algernon Grabbit
    </Signatory>
    <Capacity>
     Solicitor for the Claimant
    </Capacity>
   </Struth>
  </Claim>
 </Claim_Form>
</Pleading>
20.   It will be seen that there is a hierarchical layout: whether a Claim Form is strictly a pleading is debatable, but it is treated as being one here. It is divided into two parts: first the information contained between the <Case>...</Case> tags (which is the formal information relating to the parties, the case number and so on) and that contained between the <Claim>...</Claim> tags (which deals with the claim itself). The grammar for this Claim Form could be specified in a DTD like this:
  
  

<!ELEMENT Pleading (Claim_Form | Particulars_of_Claim |
  Defence | Witness_Statement | Application | Judgment)>
<!ELEMENT Claim_Form (Case, Claim)>
  <!ATTLIST Claim_Form part  CDATA #REQUIRED
                       court CDATA #REQUIRED
                       hr    CDATA #REQUIRED
  >
<!ELEMENT Case (Case_Number, Claimant+, Defendant+)>
<!ELEMENT Case_Number (#PCDATA)>
<!ELEMENT Claimant (Name, Address, Solicitor?)>
<!ELEMENT Defendant (Name, Address, Solicitor?)>
<!ELEMENT Name (First_Name*, Last_Name)>
<!ELEMENT First_Name (#PCDATA)>
<!ELEMENT Last_Name (#PCDATA)>
<!ELEMENT Address (Line+)>
<!ELEMENT Line (#PCDATA)>
<!ELEMENT Solicitor (Firm, Address, Reference?)>
<!ELEMENT Firm (#PCDATA)>
<!ELEMENT Reference (#PCDATA)>
<!ELEMENT Claim (Facts, Damages_Claimed, Costs, Struth)>
<!ELEMENT Facts (#PCDATA)>
<!ELEMENT Damages_Claimed (#PCDATA)>
<!ELEMENT Costs (#PCDATA)>
<!ELEMENT Struth (Signatory, Capacity)>
<!ELEMENT Signatory (#PCDATA)>
<!ELEMENT Capacity (#PCDATA)>
   Although this looks complicated, it is comparatively simple. The first line defines a Pleading as something which contains a Claim Form, Particulars of Claim or any of the other types of document specified. (Whether a judgement is a pleading again is something which is debatable. However, having said that a Pleading can contain any of these documents, this particular DTD at the moment only deals with the marking up of Claim Forms.) The vertical bar ("|") indicates that the items are alternatives.
21.   A <Claim_Form> contains two subsidiary elements, <Case> and <Claim>: it is compulsory for them both to be included. (A comma, instead of a vertical bar, indicates that both items are required, in the order in which they appear.) It can also have various "attributes" (much as in HTML the <FONT> element can have a "color" attribute as in "<FONT COLOR="Red">". The attributes for <Claim_Form> enable the user to specify whether this is a Part 7 or a Part 8 claim, which court the application is being made in, and whether it involves any Human Rights matters. (It might be appropriate to add another attribute stating whether the pleadings should be available to the public or not.)
22.   A <Case> contains a <Case_Number>, one or more <Claimant>s and one or more <Defendant>s. (A plus sign against the name of an element indicates 'one or more' of it while a question mark indicates 'zero or one'.) <Case_Number> is defined as containing "PCDATA" (parsed computer data, ie text: there is nothing in this DTD to check the format of the number). And so on.
23.   Although it is perfectly possible to produce an XML document using a text editor or a word processor but inserting the appropriate markup by hand, not many people are going to want to do that. So two questions arise: how do you create that file, and, once you have produced it, how do you use it?
24.   It is claimed that Word™ will soon be able to produce XML files and I believe that Word Perfect™ can already do so. The new version of StarOffice™ by Sun (about £50 in the UK) uses XML as its default output format and so may be able to produce legal documents marked up in XML: I have not had my copy for long enough to be able to work out if it can. However as well as the standard word processors there are already a number of dedicated XML word processors available and more are likely to appear. Three of them, in increasing order of cost, are Morphon (which runs on all platforms) XML Spy (which runs on Windows only) and Epic by Arbortext (Windows and Solaris): the latter claims to be used by many of the large legal publishers.
25.   The dedicated XML word processors at the moment have the advantage that they check that the text entered is valid. One of the problems faced by those who process text is inconsistencies. Most obvious is the numbering of paragraphs (although this is less of a problem where the "digital" form of numbering, eg 3.1.4.2, is used). 100 years or more ago those responsible for the drafting of Statutes started using a standard numbering system for numbering the Sections and divisions of Sections, eg, 3(1)(d)(ii). Almost all statutes and Statutory Instruments (and most Practice Directions) still use this form of numbering.
26.   Word™ can be used with a template intended to enforce standards such as the statutory form of paragraph numbering. English Judges use a template for judgments which are then sent off to BAILII in RTF format. Clive Freedman has written a program which converts this RTF into fully marked up HTML in the form required by BAILII. But his program unsurprisingly gets thrown from time to time because a judge has decided to do his own thing and to disregard the template: Word™ does not prevent him from doing this. A dedicated XML word processor is more restrictive and should prevent a user doing this sort of thing.
27.   If an XML document can be produced in a word processor, it can equally well be read in a word processor. It is probable that in the near future it will be possible to read such documents in all HTML browsers but that is not the case at the moment. One difficulty is that an XML DTD does deal with the question of how an XML document should be displayed on screen and so to display it either in a word processor or in a browser in the way that the author intended it will also be necessary to produce a stylesheet to tell the computer how to format it. Although Cascading Style Sheets (as used with HTML files) can be used with XML, another form of style sheet, XSL, is much more powerful. It enables calculations to be made, cross-references to be inserted and so on, and enables the document to be transformed from XML into other formats. This link shows the first page of a Claim Form produced from the XML Claim Form shown above (with the addition of a second defendant but no other changes) using an XSL stylesheet which converted it into HTML (with the assistance of the XSLT processor built into Morphon™: many browsers either have or soon will have have similar processors built in, and there are many freely available stand-alone processors). It would be possible to write a slightly different stylesheet which would enable the file to be converted into PDF, RTF, TeX or any other format.
28.   But the document can be put to many different uses. Being in a textual, rather than a binary format, it could be processed easily and fast by a computer program. It would, for example, be very easy to write a program that would take an XML Claim Form like the example shown above, to extract the relevant data from it and store that data in one or more separate records in a database.
    
  

Electronic Case Files

29.   In January 2001 Court Service issued a consultation paper called "the Modernising the Civil Courts". Many organisations, put in responses. (The SCL's response, mainly written by Laurie West-Knights QC, was I think, one of the better ones: unfortunately it seems to have gone missing from the SCL site.) The Judiciary set up a separate Working Party chaired by Cresswell J and this produced a report in which it recommended the introduction of an electronic case file. It was intended that this file should contain all the documents that would normally be used in a case including the claim form and all the pleadings. The working party was however at pains to make it clear that its members were not IT specialists and were not making any proposals as to how this should be achieved. In my view a better way of putting it would have been that the data contained in the claim form and the pleadings (and other documents) should be put into the electronic file (or database).
30.   It would, of course, be possible for the claim form in each case to be stored in the database in Word™ or PDF format. But this has a number of disadvantages. There are the points I made earlier about avoiding storing formatting information in a file. But there are also questions of redundancy and the duplication of unnecessary information. To take an example: it is a requirement of the CPRs (Rule 4(5)) that every claim form should have a copy of the Royal Arms at the top. I have heard that every year 3 million claim forms are issued---mainly debt collecting etc---but every one has the Royal Arms at the top. A low definition representation of the Royal Arms takes up about 5kb of space. There can be no point in the database storing 15 gb-worth of identical copies of the Royal Arms. There can be no point in storing in the database three million copies of details of the court opening hours (which Court Service, on whose computer this database would be stored, presumably knows), the notes that are sent to the defendant or any other formal material. On the other hand it is essential to extract from the Claim Form and to store in the database full details of the parties' addresses, telephone numbers, solicitors and so on (without formatting information) in a form in which they can be searched easily and fast.
31.   Court Service has a directory on its site containing forms in PDF format for use in proceedings. The empty Claim Form in PDF is 122kb: completed say, 125kb. The simple completed XML Claim Form set out above is under 1.3kb, ie roughly one hundredth of the size. It would be possible to store a complete XML Claim Form in the database, but it would be very easy to extract only the relevant information from the Claim Form and to store it in the appropriate fields in the record of the case: this would save yet more space and make it even more easy and fast to access the data using a command something like
  
  

SELECT case 
FROM allcases 
WHERE 
  claimant LIKE "%Smith%" 
AND 
  defendant LIKE "%Jones%"
   This would probably be done using a form, rather than actually issuing the commands listed here.
32.   When subsequent pleadings, such as the Particulars of Claim, were filed it would not be necessary to extract and store in the database the names of the parties and similar information: it would be redundant to do so and it is a principle of database design that redundancy should normally be avoided wherever possible.
33.   Once such data is stored in a database, it is equally easy to extract it and format it in various ways. Cresswell J envisaged being able to browse through the documents filed in a particular case and it would be simple to produce a program that did this. Clicking on the appropriate link would, for example, extract the details relating to the Claim Form from the database and create an on-screen version of the Claim Form "on the fly" using exactly the same systems as are used by most commercial web sites. It would be simple to include another link which would generate on request from the same data a PDF (or TeX, or RTF) version of the Claim Form which could be printed out. It would be equally easy for the software to generate on request (that is, at the time that it is asked to do so) a completely up to date zipped file containing all of the filed "pleadings" in an HTML or PDF version: the database would not contain the pleadings but simply the data contained in them; the software would, when asked to do so, convert this data into formal pleadings and zip it so that the user could download it..
34.   This link is to a very simple demonstration of the way in which this could be done using extremely silly data. Although these files were produced by hand for the purposes of this demonstration, they could, as I have said, easily have been generated "on the fly", that is to say, when asked for, from the data stored in a database. (It is not possible at present in this demonstration version to download PDF or zipped files.)
35.   The links (including those that state that a particular paragraph is referenced from elsewhere) would be inserted while the page was being created by the software: there would be no difficulty in doing this. External links (such as those in the Claimants' Skeleton Argument) could also be added automatically. (However this would not be the case if the data was in a binary format such as PDF or the output format of a word processor.) There are, of course, many things that cannot be converted into XML: scanned letters which form part of the evidence are an example, although the indexes to them can, and probably should, be in XML.
36.   Another major use of an electronic case file is in administration. Court staff (or a computer program) can, for example, check the names of the parties, their representatives and witnesses to avoid listing problems and so on. The use of such a file for case management, however, would require some substantial changes in procedure. At the moment our procedure is in the main based on service: a document may have to be filed with the Court, but the prime duty is to serve it on the other side. Most time limits depend on the date of service rather than the date of filing. It would be unacceptable under current procedure for an automated case management system to enter Judgment for the Claimant in default of defence even though the Defendant had served a valid defence in good time but failed to file it. In the United States the position is, as I understand it, different, and procedural time limits are based on the time of filing rather than the time of service (although it is necessary to certify that the document has been served on the other side).
    
  

Electronic Filing

37.   It would be very useful to have an electronic case file. But it would of course be necessary to put the relevant documents into the file. Doing this manually would be extremely time consuming and liable to error, and an automatic way of putting the document or its contents into the file would accordingly be essential.
38.   This is what "electronic filing" is about. If data is to be sent from one computer to another automatically and then acted on automatically by the latter computer there must be some protocol so that the recipient computer recognises what is being sent to it and takes the appropriate steps. There are many existing protocols on the internet: http, ftp, telnet and so on but what is required here is a protocol that acts as a wrapper for the data that is being exchanged. One protocol that might be able to provide the appropriate wrapper is an internationally agreed protocol called "SOAP". (This was originally an acronym for "small objects access protocol" but the protocol has apparently developed so much that this is no longer a correct description of it.) SOAP, which was originally designed by Microsoft™ but is now an international standard, is based on http and XML and could be used to provide the wrapper for pleadings.
39.   Electronic filing is something which on which a lot of work has been done in the US, in particular by the not-for-profit organisation "LegalXML". LegalXML, which is now part of OASIS (Organisation for the Advancement of Structures Standards), is well thought of and has many connections with the judicial authorities in the US including the Department of Justice. It has produced an XML Court Filing protocol: a description of this can be found here. Once again this is a wrapper for the document which is being filed.
40.   SOAP could be used to provide a fairly general wrapper round the documents. In other words the computer holding the case files would be told "here is a document, you decide what to do with it". The LegalXML standard would provide much more information including full details of the document itself. Because it is designed for use in the United States it has to cater for the variations in procedure that occur between States; it is also designed to be used in relation to both civil and criminal matters. As it stands I think that it may be unnecessarily complicated for use in England, but a simplified version might well be suitable, at least for the document commencing the proceedings.
41.   It is not, of course, possible to put a document into an electronic file until that file has cone into existence. The issue of a Claim Form must accordingly create the file at the same time as giving the case a unique number. The question that arises is whether all the relevant data will be in the Claim Form (or the XML equivalent of it) or whether some of it should be in the wrapper: the data will presumably include the names, addresses and other particulars (including disabilities) of the claimant and his solicitors and counsel. Amendments to this (including details in changes in representation) and further data (such as the names and addresses and so on of witnesses, or the transfer of the case to a different court ) would be made from time to time and again the question is whether these amendments should be in the wrapper or in the document being sent. I tend to the view that the main data should be in the documents.
42.   Once the case has been commenced and has a unique identifying number it is probable that less information needs to be put in the wrapper. although one thing that it will be necessary to include is details of the person filing the document. The file will have been created as the result of a Claim Form being issued by the claimant or his solicitor, but once it has been created, every document that is added to it will have to be filed electronically: it should not be possible to add documents to it manually. These documents will include orders and judgments made or delivered by Masters and Judges as well as documents filed by the parties and their advisors and so the wrapper will need to contain the name of the person filing the document and some method of identifying him, possibly using a digital signature. (The LegalXML DTD enables the names and personal details of everyone interested in the case or who might file a document to be specified: the parties, the lawyers (including their qualifications), judge, witnesses, court staff. Slightly curiously to English eyes they are described collectively as "actors".)
43.   The wrapper will also need to specify whether the document itself should be open to public inspection. It may be that fee information should also be included in the wrapper.
44.   As I have mentioned, the US civil procedure is is based on filing the relevant documents with the Court: the system is based around "filings". If you ask an English litigation lawyer to define a "filing" he will probably look at you blankly. This is not just difference in terminology. There is at the moment no direct equivalent. Similarly we do not at the moment have the equivalent of a "docket".
45.   This puts us at an advantage since we can start with a clean sheet. LegalXML's "Electronic Filing DTD" to some extent necessarily mixes up the process of filing documents with the documents themselves. Up to now most pleadings in American cases have, I have been told, been prepared in PDF. This may be because some US lawyers take the view that presentation is a vital part of "pleading"; they want to be able to specify exactly how the document should be displayed on a screen or on paper and where, for example, page breaks should occur. Preparing the document in PDF enables this to be done. But because PDF and the word processing formats which are also used are not as easy to search as an XML document, the Electronic Filing DTD provides that details of the document and its contents should be set out again in the wrapper, presumably so that the court software can decide automatically where and how to file the document. If all pleadings are in XML then this requirement goes.
46.   One State that has been experimenting with electronic filing is Georgia. Two papers describing the lessons that have been learnt, together with the DTDs and draft Rules for electronic filing can be found here. (A password is required but there is a link on the page for acquiring one.) The conclusion to the most recent paper (May 2002) is as follows:
  
   "An important part of this system is the use of industry standards, especially information exchange standards. The use of information exchange standards means that it is not necessary to develop and harmonize one system, one set of data, one set of requirements, or one set of business rules for all organizations. Rather, it is enough to allow everyone to use and develop systems tailored to individual organizational needs, but require information exchange to happen using agreed data standards (e.g., XML formats) and exchange mechanisms (HTTP, FTP, or SMTP over the Internet or an Intranet).
   START NOW
   Planning and organization are very important for any project. GCAC [Georgia Courts Automation Commission] has always planned its projects in advance and with much consideration. GCAC has been, however, very aggressive is simply starting a project, implementing, and moving forward with new projects.
   Although there are always risks in implementing ahead of, or on, the "bleeding edge," the results in Georgia have been excellent. GCAC continues to have successes in its projects. Practical experience and lessons learned from early projects compound and help advance
   Do not wait for the following:
  • Perfect and Complete Data Analysis and Modeling
  • Perfect and Complete Requirements Analysis
  • Perfect and Unanimous Political Harmony
  • Perfect and Complete Standards
  • A Large Sum of Money
  • A Still Target
   None of the above has been done by GCAC or in Georgia and none of it was required to successfully start building what is becoming a better and better system with more and more participants. This is not to say do not undertake these tasks or dream of this state of affairs. Indeed, all projects should undertake these tasks. However, experience has shown not only that a still target will never exist, but also, and more importantly, that practical experience developing systems informs and illuminates requirements rather than the other way around.
   Moving forward with practical implementations does not mean there should be no planning or a lack of vision. The future must be considered. The following items should be given strong consideration before moving forward:
  
  • Use and Development of Standards or a Framework for Standards
  • Modularization and Componentization
  • Version Control
   In Georgia, there has been great focus on these items and it has been this concentration that has made technology implemented in Georgia interoperable, reusable, and successful."
47.   Georgia has only just started using "live" data for electronic filing purposes: live filings in child support cases began on 17th May 2001. In relation to other cases it is, I understand, still experimenting.
    
  

Conclusion

48.   As probably appears from the above, I firmly believe that XML will soon become the normal output format used in the production of legal documents. It has substantial advantages in relation to pleadings, electronic case files and electronic filing.
49.   XML requires the development of DTDs or Schemas and the question that then arises is how should these be developed? In its response to the MCC Report the SCL suggested that the SCL should lead the way. In the MCC paper Court Service suggested that it should lead the way. (An alternative would be the latest legal Charity, BAILII.) I tend to the view that this sort of thing is best dealt with by a non-governmental body, but I do not think that much turns on this provided that Court Service stick to the declaration made towards the end of new Modernising the Civil and Family Courts paper that:
  
   As a key part of CTMP we will ... ensure users, advisers, judges and staff can play an active role in developing the modernisation program
50.   In the United States LegalXML has had a very great influence on the developments of standards. Although it has the support of the judicial authorities its work is carried out in the main by practitioners and academics. In my view practitioners (in the widest sense of that expression) must be fully involved in the process in this country.
   Roger Horne
Chambers of Sonia Proudman QC
11 New Square
Lincoln's Inn
London WC2A 3QB