| | Introduction
|
| | XML
|
| | Electronic Case Files
|
| | Electronic Filing
|
| | Conclusion
|
| |
|
| 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.
|
| |
|
| |
|
| 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.
|
| |
|
| |
|
| 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).
|
| |
|
| |
|
| 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.
|
| |
|
| |
|
| 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
|