sor template with feedback incorporatde · web viewthe current values are in the range:...

The LORD CHANCELLOR'S DEPARTMENT

STATUTORY PUBLICATIONS OFFICE

SPECIFICATION FOR THE PROVISION OF A STATUTE LAW DATABASE SYSTEM

STATUTORY PUBLICATIONS OFFICELORD CHANCELLOR’S DEPARTMENTSELBORNE HOUSE54-60 VICTORIA STREETLONDON SW1E 6QW

Commercial in Confidence

LORD CHANCELLOR’S DEPARTMENT – STATUTORY PUBLICATIONS OFFICESpecification for the Provision of a Statute Law Database System

CONTENTS

1 INTRODUCTION.................................................................................................. 3

1.1 REQUIREMENT..........................................................................................................1.2 PROJECT OBJECTIVES...............................................................................................1.3 SCOPE......................................................................................................................1.4 PROJECT MANAGEMENT METHODOLOGY..................................................................1.5 SUPPLIER RESPONSIBILITY........................................................................................

2 BUSINESS BACKGROUND.................................................................................. 4

2.1 LORD CHANCELLOR'S DEPARTMENT ......................................................................42.2 STATUTORY PUBLICATIONS OFFICE........................................................................52.3 STATUTE LAW........................................................................................................ 52.4 STATUTORY PUBLICATIONS OFFICE IT INFRASTRUCTURE........................................62.5 OVERVIEW OF THE CURRENT SYSTEM......................................................................72.6 REPLACEMENT SYSTEM.........................................................................................112.7 FUNCTIONAL REQUIREMENTS................................................................................112.8 DATA REQUIREMENTS...........................................................................................112.9 AUDIT REQUIREMENTS..........................................................................................122.10 NUMBER OF USERS.............................................................................................. 122.11 VOLUMES........................................................................................................... 12

3 OPERATIONAL REQUIREMENTS...................................................................14

3.1 SYSTEM SOFTWARE REQUIREMENTS.....................................................................143.2 SYSTEM HARDWARE REQUIREMENTS....................................................................143.3 SYSTEM DATABASE DESIGN AND INSTALLATION REQUIREMENTS..........................143.4 SYSTEM PERFORMANCE REQUIREMENTS...............................................................153.5 YEAR 2000 COMPLIANCE....................................................................................... 153.6 DATA INPUT CONTROLS AND VALIDATION.............................................................153.7 DATA OUTPUT CONTROLS AND VALIDATION...........................................................163.8 SYSTEM MAINTENANCE AND SUPPORT REQUIREMENTS...........................................163.9 SYSTEM DOCUMENTATION REQUIREMENTS............................................................163.10 TRAINING REQUIREMENTS...................................................................................173.11 SUPPORT REQUIREMENTS....................................................................................173.12 USER INTERFACE REQUIREMENTS........................................................................183.13 SYSTEM HELP REQUIREMENTS.............................................................................183.14 SYSTEM ACCESS CONTROL REQUIREMENTS.........................................................183.15 SYSTEM INTEGRITY AND MONITORING REQUIREMENTS.........................................193.16 SYSTEM AVAILABILITY AND RECOVERY REQUIREMENTS.....................................203.17 SOFTWARE RELEASE VERSION..................................................................20

4 CONTRACTUAL REQUIREMENTS.................................................................21

4.1 LIAISON................................................................................................................ 214.2 CONTRACT PERIOD............................................................................................... 214.3 PERSONNEL.......................................................................................................... 214.4 VARIATIONS......................................................................................................... 214.5 TRAVEL AND SUBSISTENCE.................................................................................... 224.6 INVOICE AND PAYMENT........................................................................................22

____________________________________________________________________________________Author: KP Page 1Issued: Commercial in Confidence Issue No: 1.0


4.7 THE SUPPLIER....................................................................................................... 224.8 INTELLECTUAL PROPERTY RIGHTS............................................................22

5 IMPLEMENTATION AND SYSTEM ACCEPTANCE REQUIREMENTS….23

5.1 IMPLEMENTATION TIMETABLE..............................................................................235.2 SYSTEM ACCEPTANCE...........................................................................................235.3 APPLICATION TESTING........................................................................................... 235.4 SOFTWARE RELEASE.............................................................................................. 23

ANNEXES

ANNEX A - Outline Project Timetable………………………………………………..24

ANNEX B - Health and Safety (Display Screen Equipment) Regulations 1992………25

ANNEX C – Functional Requirements………………………………………………..26

ANNEX D – Data Requirements……………………………………………………....29

ANNEX E – Editorial Overview………………………………………………………46

ANNEX F – Examples of Legislation…………………………………………………52

ANNEX G – Functional Requirement for the Enquiry System………………………..53

ANNEX H - SGML and XML DTDs…………………………………………………57

ANNEX I – GLOSSARY……………………………………………………………..58



1 INTRODUCTION

1.1 Requirement

1.1.1 This Specification, which shall form part of the Contract, sets out the requirement for the implementation and maintenance of a replacement Statute Law Database system (referred to as "the system"). The new system will be based around the use of an authoring package that enables the management, revision and storage of legislative documents in Extensible Markup Language (XML).

1.2 Project Objectives

1.2.1 The main objectives are:

Provision of a package based facility, using Extensible Markup Language (XML) format, for editing and maintaining an electronic database of UK Statute Law;

To provide training for the editorial and support staff in the use and maintenance of the system;

To provide a system that is resilient and upgradeable in terms of processing power, data storage and software; and

To provide a system that enables SPO to distribute and share information held in electronic form.

1.3 Scope

1.3.1 The requirement is for:

i) the development, supply and set-up of the system;

ii) the supply of all documentation required to enable the users to use the system;

iii) the installation of the system on the network currently used by SPO;

iv) any training required by the users to enable them to use the system;

v) any technical or other consultancy support required by SPO to enable it to undertake: user acceptance testing; data conversion; technical acceptance; post implementation review and; any other system related tasks (subject to change control);

vi) the maintenance of the system for a period of one year from the date on which it goes live. The Supplier will be expected to state that it is capable of supporting the system for the entirety of its life. The Supplier should note, however, that it is the LCD’s policy to enter into/renew maintenance Contracts on an annual basis. The term “life of the system”, is hereafter intended to indicate up to five years from implementation, but will extend as long as the SPO continues to use the system operationally;



vii) the supply, set-up, documentation, installation, training, maintenance and support (period as in vi above) for any software, hardware, communications or other equipment provided by the Supplier under this Contract.

1.4 Project Management Methodology

1.4.1 LCD will use elements of the Projects in Controlled Environments (PRINCE 2) project management methodology to manage the implementation of the system. The Supplier is expected to utilise industry standard quality assurance techniques throughout the life of the project.

1.5 Supplier Responsibility

1.5.1 Whilst every endeavour has been made to give the Supplier an accurate description of the system requirements in this document, the Supplier should form its own conclusions about what is necessary to meet the requirements. The LCD cannot accept any responsibility for the Supplier’s interpretation or assessment of the requirements (see paragraph 4.7).

2. BUSINESS BACKGROUND

2.1 The Lord Chancellor’s Department

2.1.1 The Lord Chancellor’s Department is responsible for:

promoting general reforms in the civil law;

the procedure of the civil courts;

the administration of the Supreme Court (Court of Appeal, High Court and Crown Court) and county courts in England and Wales;

legal aid schemes; and

maintaining the whole of the statute (ie made by Parliament) law for Great Britain, including Westminster legislation extending to Northern Ireland.

2.1.2 The Minister responsible for the LCD is the Lord Chancellor who by his office is also responsible for advising the Crown on the appointment of senior judges (Circuit judges and above). The Lord Chancellor himself appoints members of the lower judiciary and certain other officers.

2.2 Statutory Publications Office (SPO)

2.2.1 The SPO forms part of the Corporate Services Group within the Lord Chancellor’s Department. The primary purpose of the SPO is to produce revised editions of the statutes. Until 1991 this was achieved in the hard copy publication Statutes in Force. Since that date it has been the aim of SPO to present the revised statute book in an electronic format. This aim led to the development of the Statute Law Database (SLD) system.



2.2.2 The SLD system is comprised of an editorial database and an enquiry database. The enquiry database is a searchable database of current and revised legislation. Primary legislation is updated to show the current position of the law whilst retaining earlier versions as part of an historic record.

2.2.3 Within SPO there is a Data Management team (3 staff) and an Editorial team (14 staff). The Data Management team is concerned with the structure and content of the electronic files and also undertakes system management and administration tasks. The Editorial team is responsible for interpreting and applying amendments arising from subsequent legislation to produce revised versions of the statutes. This team also adds value to the basic text of an Act by creating commentary appropriate to the effects and identifying attributes such as geographical extent. At least 6 staff within the Editorial team are charged with ensuring the achievement of high levels of accuracy, developing editorial policy and providing advice to other editors.

2.2.4 The SPO currently has around 600 external users of the enquiry database and there is a team of 3 staff running a helpdesk facility.

2.3 Statute Law

2.3.1 Statute Law is law created by Parliament. There is a substantial body of statute law, with some 3,700 Acts currently in force. While the bulk consists of modern statutes they do stretch back to 1267. In addition, Statutory Instruments and other subordinate legislation are closely associated with the statute law and maybe used as a means of bringing into effect or modifying existing Acts.

2.3.2 Statute law is the principal means of giving effect to Government policy. It also provides the framework for the implementation of Government policy using subordinate legislation and by administrative action.

2.3.3 Statute law text is highly structured data whose structure, as reflected in the layout of text on the printed page, has legal effect. The incidences of white space, both vertically and horizontally, frequently has legal consequences.

2.3.4 The ready availability of text and other information concerning statute law is essential to the machinery of Government and Parliament. All those who are subject to legislative rules, as well as the enforcing and administering authorities, require access to the rules.

2.4 SPO IT Infrastructure

2.4.1 The SPO accesses the Statute Law Database (SLD) and automated office applications through a networked desktop service supplied and supported by Liberata Group Ltd, under a PFI Contract known as the ARAMIS Contract. [LCD signed a Contract with Liberata (formerly CSL Group Ltd) in December 1996 and commenced on 5th January 1998 for a period of 9 years. The services provided by Liberata include Accounting, Fixed Assets, Receipts, Payments (including Travel and Subsistence), Write-offs, Purchasing Monthly and local Fees Payroll, Banking and Cash Carrying. In addition they also provide a desktop IT service to around 2800 users. The scope of the service is known as



the ARAMIS Domain, consisting of a number of Local Area Networks connected by a wider area network. The servers are mainly running Windows NT4 with a few areas running Windows 2000.]

2.4.2 The LAN in LCDHQ (Victoria Street) is ethernet based, with structured data and voice cabling running 100Mb over copper and fibre backbone. Data and applications are held on Windows NT servers. A CISCO switch is used at the core and has a router module and policy feature card. Users connect to the LAN via CISCO 4000 switches. The switches are configured so that users are logically grouped together in VLANs. A DHCP server allocates IP addresses to clients rather than hard coding client PCs.

2.4.3 The standard desktop software that is currently used is MS Office 97, MS Outlook 98, Visio v5, Adobe Acrobat Reader v5 and Internet Explorer v5.5.

2.4.4 At the Desktop, the PCs are Dell Optiplex G1s with PII, 200Mhz and 64Mb RAM, although replacement machines are P4, 1Ghz and 256Mb RAM. The hardware and software used in the ARAMIS Domain is subject to change and it should therefore not be assumed that the current configuration will remain.

2.4.5 Printing is normally provided by HP laserjet 4 machines and attached via a PC. However, within SPO some printers are networked.

2.4.6 The SLD consists of a system that supports the data take-on and editorial processes and a system that provides an end user enquiry facility (web system). There are 5 main Unix servers and a WWW server.

2.4.7 Data is encoded with SGML tagging in accordance with the Document Type Definitions (DTDs) (see Annex H for copies). Images are scanned, held in .TIF format and loaded separately on to the system. References for each image are enclosed within an attribute field within a specified SGML tag. These tags act as anchor points for the associated images.

2.4.8 Once the SGML data is published onto the enquiry system (via Web filters that convert the SGML to an HTML format, and the images converted to .GIF format), the images will automatically embed into the HTML document version once the document is selected for viewing.

2.4.9 The editorial system utilises the Interleaf5 desktop publishing package (SGML editor).

2.5 Overview of the Current System

2.5.1 The current IT system supports all the processes associated with the loading of new legislation, revision of existing legislation and provision of an enquiry facility. The Stationery Office are under Contract to supply data in electronic format, known as SGML (Standard Generalised Mark-up Language) and images in .Tif format.

2.5.2 The Data Management team is responsible for loading the data and validating it in terms of consistency with the input Document Type Definitions (DTD). There



are two classes of DTD (one for primary legislation and one for secondary legislation) that define the structure and consistency of an electronic document according to legislation type and the defined format type. There are two further types of DTD, known as system DTDs which are derived from the input DTDs but customised to enable editorial amendment to take place. These enable the structure to remain compliant within the bounds of certain Interleaf constraints. The Data Management team using native Interleaf tools carry out any corrective work. The editorial team uses the same software package, but in a heavily customised form. The document passes through a variety of “states” during the load and editorial processing. The status of a document is indicated by a suffix to the name – “L” for “Loaded”, “C” for “Corrected”, “U” for “Updated” and “P” for “Publishable”.

2.5.3 When the document has successfully passed validation it is then made available to the editorial team. The Data Management team also “publish” to the enquiry database once per week, which offers enquiry users access to the new and recently revised statutes.

2.5.4 SPO also receive a hard copy of the legislation which is “marked-up” by experienced senior editors. The process of marking up involves identification of the individual effects, contained within the new piece of legislation, as they relate to existing legislation. The marked up document is then used by the editorial staff to revise the appropriate legislation. Using the customised version of Interleaf, they revise the text and add value to the bare text by adding commencement details, geographical extent and explanatory commentary where necessary. Management controls are in place for allocation of work and the monitoring of progress. These controls include the use of in-house developed non-integrated spreadsheets.

2.5.5 Workflow

Another way of looking at the editorial process is to examine the workflow. Legislation enters the system and is subjected to a series of transformations, which take it through a variety of states. This is illustrated in the following workflow diagram



2.5.6 New legislation is supplied in electronic format (SGML) by TSO. This raw ‘tagged’ data is converted and enriched using a text editor to produce a document that will conform to a valid system load format. It is then checked to ensure the text, structure and references are correct and is then either accepted as a publishable document or rejected for corrective work. The document is then Edit Corrected, which involves setting document attributes (commencement dates, geographical extent etc.) and adding explanatory



commentaries. The document is then reviewed and approved and once again becomes publishable. The approved publishable document then enters the cycle of editorial maintenance, review and approval along with the existing legislation on the database. The document is updated, amending the text and/or adding value through commentaries in accordance with the effects of subsequent legislation. It is then reviewed and either approved or re-updated. Each subsequent amendment generates another iteration of the ‘update-approval’ cycle, resulting in an updated publishable document.

[A whole Act (Primary legislation), Statutory Instrument (Secondary legislation) or other piece of legislation is referred to, in SLD jargon, as a “Lex” (“Lex being the Latin for law, plural “leges”). Each provision (e.g. section of an Act, paragraph of a Schedule, article of a Statutory Instrument, etc.) or other distinct element of legislative text is called a “lex element”. Whenever there is a change to the text a new version of the lex element is created containing those changes, whilst the earlier version(s) are retained for historical information. Each version is known as a “lex element version (lev).]



2.5.7 Storage Architecture

The schema used to store the documents on the existing editorial system is hierarchical and complex. The structure, in this instance showing Primary in lower level form, is described in the following diagram (There is a similar structure for Secondary):

The top level “Lex Class” separates the broad categories of legislation “Primary” and “Secondary”. “TIF Image Store” is the repository holding .TIF images required within the body of the text such as the royal crest that appear in the documents. The “Lex Type” level subdivides the broad categories into the specific types of legislation. Within each specific document type there is a separate folder for each calendar and regnal year. The individual chapter documents could logically be held within their re-spective “Year / Regnal Year” folders but to reduce the quantity of docu-ments that might appear in some folders, additional layer of “Chapter



Group” folders are inserted to make the documents more manageable. There is a separate folder for each group of fifty chapters. Finally, the doc-ument files are held within the “Chapter Group” folders. Each item of le-gislation is identified by its “Chapter” or other number. N.B. Very large documents have themselves been split up into a series of sub-documents sub-divided at Part level or level decided by an authorised editor.

2.6 Replacement System

2.6.1 It is anticipated that the new system will continue to provide support for the editorial processes and application of the rules (see Annex E for Editorial Overview). It will also meet the requirements for importing data onto the database, as part of the daily business and for the export of data in XML format, within agreed Specifications. There will also be a facility for the initial data take-on of existing data (see Annex D - Data Requirements).

2.6.2 The system should be capable of operating with the minimum of internal system management, outside of normal administration and housekeeping processes and should be capable of supporting remote access.

2.6.3 The Stationery Office will be responsible for providing legislation documents in XML format consistent with pre-defined input DTDs. These will need to be loaded daily onto the system in batch mode. After initial validation procedures editors will be able to either correct those that have failed the validation or begin the process of editorial update. System DTDs, to enable editorial revision work, do not have to be agreed with TSO but can obviously be subject to changes through future modifications being made to the input DTDs.

2.6.4 Output from the new system will be provided to the Knowledge Network team who are part of the Government’s e-Envoy office. They will be hosting the “published” version of the database and will be providing enquiry facilities to Government Legal Service. Although not directly related to this procurement the LCD set up an End User Group to establish their likely requirements for an enquiry service. This was to assist in the identification of any changes that would need to be taken into account as part of the Specification and development of this system. To help the Supplier understand how the output of this system will be used, Annex G – Functional Requirement for the Enquiry System has been included in this document for information purposes only. [Annex G is a Statement of Requirement between Enquiry Users and the combined resources of Knowledge Network and LCD teams only.]

2.7 Functional Requirements

2.7.1 The Functional Requirements are specified at Annex C.

2.8 Data Requirements

2.8.1 The Data Requirements are specified at Annex D.



2.9 Audit Requirements

2.9.1 (D) The system SHOULD provide a facility for logging principal user activity (audit log), enabling the tracing and interrogation of transactions.

2.10 Number of Users

2.10.1 (HD) Initially, the number of concurrent system users will be 22, although there is a separate (outside of this Specification) proposal that the software used by the editors could also be made available for use by up to 300 legislative draftsmen in the Government Legal Service to produce legislation from the stages of draft to final version. To allow for this possibility, the Supplier SHOULD identify options that could allow this service to be implemented.

2.11 Volumes

2.11.1 Business transaction volumes (average) per annum are:

Public General Acts 45 (3689 electronic pages)

Local Acts 8 (165 electronic pages)

Scottish Acts 12 (250 electronic pages)

Northern Ireland Acts 5 (155 electronic pages)

Statutory Instruments 1716 (11058 electronic pages)

Welsh Statutory Instruments 60 (500 electronic pages)

Local Statutory Instruments 143 (632 electronic pages)

Scottish Statutory Instruments 270 (1973 electronic pages)

Local Scottish Statutory Instr. 10 (50 electronic pages)

Statutory Rules 28 (378 electronic pages)

General Synod Measures 1 (21 electronic pages)

Archbishops’ Instruments 4 (4 electronic pages).

2.11.2 Average transactions are 10 Statutory Instruments per day (these sometimes arrive in batches of up to 50), 2 Acts per week (although these usually arrive in batches of between 5 and 7 a year, per Royal Assent of which there are approximately 8 per year). Annual transaction volumes for Images is approximately 900. The bulk of which relates to secondary legislation.

2.11.3 The current size of the Interleaf database is 26.7Gb (this includes the backup (,1) files, and L, C and U States) populated with nearly 26,000 documents. There are 10,000 images currently sized at 7Gb. In terms of electronic pages, there are



approximately 153,000 for secondary legislation and 137,000 for primary legislation.

2.11.4 The largest document on the system is 1988 Chapter 1 Income and Corporation Taxes Act (ICTA) and currently has a size of 80Mb.

2.11.5 There are on average 15,000 new effects/amendments per year.



3 OPERATIONAL REQUIREMENTS

3.1 System Software Requirements

3.1.1 (M) All system functions MUST be accessible from menu options without recourse to operating system level commands.

3.1.2 (HD) The system SHOULD be capable of being managed by a (user) System Manager (the use of the term “System Manager” includes reference to the Deputy System Manager in addition throughout this document) with the minimum of specialist training.

3.1.3 (M) The system MUST allow access to multiple users in any mode (i.e. update or retrieval).

3.1.4 (M) It MUST be possible to increase the number of users and/or the number of concurrent system users if required, subject to system constraints.

3.1.5 (M) The Supplier MUST confirm that the system will be able to run on servers and PC clients running under any of the current MS platforms.

3.1.6 (M) The Supplier MUST be able to undertake any post system acceptance system amendments required by the LCD, subject to change control.

3.1.7 (M) The Supplier MUST inform the LCD if the latter will be liable to pay any royalties for any “custom controls” that will be used by the system.

3.2 System Hardware Requirements

3.2.1 (M) The Supplier MUST specify their requirements for hardware that will provide sufficient processing power, memory and backup storage capacity and transfer speed to cater for all dialogues and processes for the life of the system. It is expected that the Supplier will develop the system on their premises and load and configure the system onto an existing internal hardware platform.

3.2.2 (M) The Supplier MUST also state the minimum and recommended specifications for their system to operate in a Microsoft Windows NT client and server environment.

3.3 System Database Design and Installation Requirements

3.3.1 (D) Where appropriate, the LCD’s preferred application databases are Microsoft Access and Microsoft SQL Server. The preferred development language is Microsoft Visual Basic. Supplier proposals SHOULD conform to these standards.

3.3.2 (M) Where a Supplier wishes to propose alternatives, the Supplier MUST specify the reasons for their choice.



3.4 System Performance Requirements

3.4.1 (M) All on-line functions, which involve the update or enquiry of a single main data object (e.g. a retrieval made on file reference number), MUST be capable of responding within five seconds on all occasions. This target MUST be met at all levels of system loading up to full system demand.

3.4.2 Full system demand is defined as the database fully loaded with five years’ data based upon:

i) the data growth figures specified by the Specification;

ii) the maximum number of concurrent users (SLD system not network and not Government Legal Service) that this Specification specifies as 'unlikely to exceed'; and

iii) no other users using the server, upon which the system has been installed.

3.4.3 Response time is defined as the period between the issue of a command and the application providing a response on the screen of the terminal that issued the command.

3.4.4 (M) The Supplier MUST state where any other on-line function is likely to respond in greater than five seconds and these MUST be agreed with the LCD.

3.5 Year 2000 Compliance

3.5.1 (M) The Supplier MUST confirm that:

i) No value for the current date will cause any interruption to the performance and functionality of the software;

ii) All manipulations of time and date related data will produce the correct results for all valid date values within the application;

iii) Data elements in interfaces and data storage will permit specifying the century to avoid ambiguity; and

iv) Where date elements are represented without a century, the correct century shall be derived for any processing of that date element.

3.6 Data Input Controls and Validation

3.6.1 (M) The following types of validation MUST be undertaken automatically by the system when data is input:

i) check that data items are the correct size;

ii) check that data is in the correct format;

iii) check that data is within the specified range.



3.6.2 (M) The following data integrity rules MUST be performed automatically by the system when data is input:

i) the system MUST ensure that data integrity will be maintained before information is updated, e.g. apply cross-field validation, prevent illegal duplicates, or prevent partial data input;

ii) the system MUST prevent information being updated and committed to the system’s database, or equivalent, if it has failed validation checks;

3.6.3 Detailed system specific validation requirements will be agreed with the Supplier during the Supplier’s detailed analysis of the system requirements post award of Contract.

3.7 Data Output Controls

3.7.1 (M) All standard report layouts MUST be agreed with the LCD during the Supplier’s detailed analysis of the system requirements post award of Contract.

3.7.2 (D) All reports SHOULD have a report header and end of report indicator and the pages SHOULD be numbered.

3.7.3 (D) It SHOULD be possible to reproduce all regular reports on an ad hoc basis.

3.7.4 (HD) It SHOULD be possible to re-start print programs from any given page and print any selected page.

3.8 System Maintenance and Support Requirements

3.8.1 (M) The Supplier MUST be able to maintain and support the system for the life of the system (see paragraph 1.3.1(vi)).

3.9 System Documentation Requirements

3.9.1 (M) The following documentation MUST be provided, and updated with changes made during the lifetime of the system, by the Supplier (post award of Contract):

i) system user manual;

ii) system manual for the System Manager;

iii) operation manuals for any other software, hardware, communications or other equipment provided by the Supplier for the system.

3.9.2 (D) All documentation provided SHOULD:

i) be paginated and contain a comprehensive index and glossary;

ii) be written in Plain English, avoiding jargon and, wherever possible, technical terms;



iii) have a standard presentational format which is set out in an easy to follow manner;

iv) cover all areas of the system to which the user has access, including user level troubleshooting and error handling instructions;

v) cover all reasonable system eventualities.

3.9.3 (M) Any technical terms that have to be used MUST be included in a glossary.

3.9.4 (M) The documentation referred to above MUST be provided in hard copy.

3.9.5 (D) The documentation referred to above SHOULD be provided in electronic format.

3.10 Training Requirements

3.10.1 (M) The Supplier MUST provide adequate training for the System Manager and members of the SPO Acceptance Testing team, for acceptance testing purposes and full training for the System Manager and all other system users pre system go live.

3.10.2 (M) The Supplier MUST provide training for the System Manager and all other system users post system go live if required to do so by the LCD (for the duration of the life of the system).

3.10.3 (D) The Supplier SHOULD specify their strategy on how continuity of training will be achieved.

3.11 Support Requirements

3.11.1 (M) The Supplier MUST be able to provide technical or other consultancy support for the LCD during the acceptance testing, data conversion and any other pre system acceptance stages if required to do so by the LCD.

3.11.2 (M) The Supplier MUST be able to provide technical or other consultancy support for the LCD post system acceptance if required to do so by the LCD (for the duration of the life of the system).

3.11.3 (M) The Supplier MUST state the applications support options that they can offer where the following system failures have occurred:

Critical Where a system problem is preventing normal business activity;

Urgent Where a problem is seriously impacting on normal business activity:

Non-urgent Where a problem is causing an interruption to normal business activity, but can be effectively worked around.



3.11.4 (HD) The Supplier SHOULD provide an on-line support facility, available between the hours of 9am to 5pm, from Monday to Friday excluding public holidays.

3.11.5 (HD) The on-line support service SHOULD be the single point of contact for the reporting of system failures.

3.12 User Interface Requirements

3.12.1 (M) The system MUST conform to the Health and Safety (Display Screen Equipment) Regulations, 1992, as given at Annex B.

3.12.2 (M) The Supplier MUST agree during the design stage, the standards to be adopted for screen design, to ensure a consistent 'look and feel' across all user interfaces.

3.12.3 (M) All individual screen layouts MUST be agreed with the LCD during the Supplier’s detailed analysis of the system requirements post award of Contract.

3.12.4 (M) Error messages MUST be in English.

3.12.5 (HD) Error messages SHOULD clearly describe the error.

3.13 System Help Requirements

3.13.1 (HD) The system SHOULD have an on-line help facility, which:

i) SHOULD be context sensitive;

ii) SHOULD be consistent with any software package tailoring undertaken, if applicable.

3.13.2 (M) The Supplier MUST state their proposals for the on-line help of the system.

3.14 System Access Control Requirements

3.14.1 (M) The system MUST restrict access to the System Manager for access to system management functions, which MUST be password protected. System management functions include user account management and database management.

3.14.2 (M) The Supplier MUST provide a mechanism for the System Manager to create, amend and delete user accounts for the system.

3.14.3 (HD) This function SHOULD permit the maintenance of group memberships.

3.14.4 (M) The Supplier MUST provide a mechanism for the System Manager to define which functions users or user groups are permitted to use.

3.14.5 (M) System functions MUST only be available if a successful log-on is achieved.



3.14.6 (M) Each user MUST be uniquely identified by way of a user identifier and a password.

3.14.7 (M) The system MUST provide a facility to lock out a user following three unsuccessful log-in attempts.

3.14.8 (M) User identifiers MUST only be assigned by the System Manager.

3.14.9 (M) Users MUST choose their own passwords.

3.14.10(M) The System Manager MUST be prevented from knowing the user passwords, once the user has chosen them.

3.14.11(M) Passwords MUST consist of not less than six alphanumeric characters and be suppressed from display on terminal screens on input.

3.14.12(D) Passwords SHOULD be encrypted.

3.14.13(HD) The system SHOULD enforce regular password changes.

3.14.14(M) If a user forgets his password the system MUST allow the System Manager to reset the password to a default.

3.14.15(M) After reset the user MUST be forced to change their password.

3.14.16(D) The system SHOULD 'stamp' records with the date/time and user identifier each time they are updated.

3.14.17(D) The Supplier SHOULD provide a means of extracting this information for reporting purposes.

3.15 System Integrity and Monitoring Requirements

3.15.1 (M) The system MUST provide the capability of preserving the integrity of data during update operations, e.g. two users attempting to update the same data simultaneously.

3.15.2 (M) The Supplier MUST implement the system using a “pessimistic” locking strategy. Whenever a user starts to modify a record the system MUST prevent another user from updating the same record. If another user is already updating a record, the system MUST notify the second user that the record is already being updated.

3.15.3 (D) If another user is already updating a record, the system SHOULD notify the second user that the record is already being updated and the username of the first user.

3.15.4 (M) The Supplier MUST state the locking mechanism of their proposed database management software, where an alternative to the LCD's strategic databases are proposed, i.e. Microsoft Access and SQL-Server.



3.15.5 (D) Facilities SHOULD be provided to enable the database to be examined to check for possible inconsistencies in the data organisation (e.g. integrity checks to ensure that the correct links exist between related records).

3.15.6 (M) It MUST be possible to restore data to the database in the event of system, hardware, software, or other faults.

3.16 System Availability and Recovery Requirements

3.16.1 (M) The system (plus any additional software, hardware, communications or other equipment) maintainer MUST respond to system faults within four hours of being notified and fix “non-serious” faults within a further four hours during normal working hours.

3.16.2 (M) Full system recovery following a “serious” system fault MUST be achieved within two working days of the fault being reported.

3.16.3 (M) Recovery procedures MUST be clearly defined and documented.

3.16.4 (HD) It SHOULD be possible to recover the system database after a non-destructive failure to the point of the last completed update transaction.

3.17 Software Release Version

3.17.1 (M) The system MUST display the release version of the software.



4 CONTRACTUAL REQUIREMENTS

4.1 Liaison

4.1.1 Within the LCD the Project Manager, (or any other person appointed as such), will be the Contract Manager and responsible for the day to day running of the Contract.

4.1.2 The LCD shall make available the appropriate people for meetings and consultation as agreed between the LCD and the Supplier.

4.1.3 The Supplier shall provide check point reports by Monday noon each week for the previous week, to attend project management meetings as required and to maintain an up to date detailed project plan using the LCD’s standard planning tool.

4.1.4 The Supplier shall provide all necessary technical support for the system.

4.2 Contract Period

4.2.1 The Contract shall commence on the date of the letter of acceptance and continue until all aspects of the requirement have been carried out to the satisfaction of the Project Manager. However, the LCD may, by giving seven days notice in writing, terminate the Contract at any stage of the requirement.

4.2.2 The LCD shall reimburse the Supplier against any commitments, liabilities or expenditure reasonably incurred up to the point of termination. However, the Supplier shall not be entitled to any severance payment or compensation for loss of profits.

4.2.3 This is in addition to all other rights of termination.

4.3 Personnel

4.3.1 Personnel named by the Supplier within the Contract shall be available for the duration of the Contract and shall not be replaced without the prior written agreement of the Project Manager.

4.4 Variations

4.4.1 If any variations become necessary to the services to be supplied under this Contract either party must immediately provide full details of the proposed variations to the other and give not less than five days notice unless otherwise agreed by the Project Manager. No alteration, addition or omission from this Specification shall be implemented without the written agreement of both parties.

4.5 Travel and Subsistence

4.5.1 The LCD shall pay travel and subsistence only should the Supplier be required by the Project Manager to travel to the Court Service or other associated offices.



These must be expenses necessarily incurred and actuals. These will be paid up to the maximum shown on the Price Schedule. Travel may be first class and subsistence will not exceed Civil Service Class 2 rates. The Supplier may claim travel by car at the Public Transport rate of 25.5p per mile.

4.6 Invoices and Payment

4.6.1 The Supplier shall submit an invoice to the LCD upon, in the opinion of the Project Manager, the satisfactory completion of each stage of the Project or as agreed with the Project Manager. Each invoice must be submitted to the Project Manager within 14 days and must quote the completion charge on the basis of prices tendered.

4.7 The Supplier

4.7.1 No claims by the Supplier for additional payments will be allowed on the grounds of misunderstanding or misinterpretation due to lack of knowledge of the requirements as set out in this Specification.

4.8 Intellectual Property Rights

4.8.1 All rights, title and interest in any Intellectual Property Rights, including but not limited to those embodied in any:

(a) designs, architectures, technical configurations, business processes or working practices;

(b) Computer Software;

(c) logos, trade marks, domain names and/or other names, addresses or brands; and/or

(d) reports, manuals and/or other documentation (whether in hard copy or electronic format), including any preparatory versions of the same, which relate in any way to the design, development or operation of the requirement or to the delivery of the requirement;

which are specifically generated by the Supplier, or specifically generated by any of its sub-contractors or agents and subsequently acquired by the Supplier, in the design and development of the requirement or in the delivery of the requirement shall belong to an be the absolute property of the Crown and automatically vest in the Crown without further formality on coming into existence. In no circumstances shall the Crown acquire title to the Intellectual Property Rights in the Libraries of Software and the Pre-Existing Intellectual Property rights.



5 IMPLEMENTATION AND SYSTEM ACCEPTANCE REQUIREMENTS

5.1 Implementation Timetable

5.1.1 (M) A proposed timetable is attached at Annex A. The Supplier MUST either:

a) state that they are able to adhere to the LCD’s implementation timetable;

or

b) state that it is able to adhere to the LCD’s procurement timetable and provide its alternative implementation timetable stating the date on which the system would commence full live running.

5.2 System Acceptance

5.2.1 System acceptance will be subject to satisfactory completion of acceptance testing which will be specified and conducted by the LCD.

5.3 Application Testing

5.3.1 (M) The Supplier MUST supply copies of its application test plans upon request from LCD.

5.3.2 (M) The Supplier MUST test the system in an environment which mirrors the proposed live environment as closely as possible, unless agreed otherwise by LCD.

5.3.3 (M) All releases MUST be tested by the Supplier to the Supplier’s own internal quality assurance procedures, except where agreed beforehand by LCD.

5.4 Software Release

5.4.1 (M) Each release of software MUST be supplied with an incremental version number.

5.4.2 (M) Each release of software MUST be supplied with appropriately amended manuals, except where agreed by LCD.



Annex A

Outline Project Timetable

Key Activity/Milestone Expected Completion Date

Invitation to tender issued to Suppliers 18th October 2002

Presentation of the current system 5th November 2002

Supplier Responses Received 29th November 2002

Initial Evaluation 5th and 6th December 2002

Supplier Presentation 12th December 2002

Final Evaluation 19th December 2002

Award Contract 20th December 2002

System Installation 4th June 2003

User Testing 9th June 2003

Implementation 4th July 2003

System Live 28th July 2003



Annex B

SI 1992/2792 Health and Safety(Display Screen Equipment) Regulations 1992

Author: KP Page: 25 Issued:

Commercial in Confidence Issue No: 1.0


Annex C

Functional Requirement

C1. (M) The Supplier MUST specify their proposals for the initial loading of data and for loading data as part of the daily process.

C2. (M) It MUST be possible for the on-line construction of an entire piece of legislation by editorial staff.

C3. (M) It MUST be possible for an editor to alter the document structure within the constraints of a valid DTD.

C4. (M) It MUST be possible to view a document in a format that is consistent with the Queens Printer hard copy, including any tables or images.

C5. (M) It MUST be possible to navigate through a document by different methods. Typically this will include scrolling, page specification, section specification, use of tree structures and word/phrase searches.

C6. (HD) Where a word/phrase search facility exists then it SHOULD be possible to ignore the use of markers or tags that appear within the text string but do not form part of the original text.

C7. (D) It SHOULD also be possible to use a word/phrase search and replace facility.

C8. (M) The system MUST offer a facility to change the font characteristics of any text (e.g. style, size etc.).

C9. (M) It MUST be possible to view a document with and without the tagging produced by the authoring package.

C10. (M) It MUST be possible to open more than one document at a time, to enable the editor to view and work on multiple documents in the same session.

C11. (M) It MUST be possible to print all or any specified part of a document.

C12. (M) It MUST be possible for the editor to select any existing version of the document or provision.

C13. (M) It MUST be possible to create any number of new versions of a provision (whether successive, concurrent or prospective).




C14. (M) It MUST be possible for editors to record and maintain “start” and “stop” dates attributed to the whole document and to each version of any provision.

C15. (M) It MUST be possible to record and maintain the basic geographical extent attributed to the document as a whole and to each version of any provision.

C16. (M) It MUST be possible to record and maintain information that shows that a provision makes a blanket amendment.

C17. (M) It MUST be possible to record and maintain information that shows whether a provision contains a power to make subordinate legislation.

C18. (M) It MUST be possible to record and maintain subject against an item of legislation.

C19. (M) It MUST be possible to amend the text of a provision.

C20. (M) It MUST be possible to insert and delete an image that forms part of the provision.

C21. (M) Within the same document, it MUST be possible, through the use of a single operation, to repeal a whole provision, a sub-provision, a single word and a selection of words.

C22. (D) It SHOULD be possible to repeal a whole Act or a range of provisions or sub-provisions through the use of a single operation.

C23. (M) It MUST be possible to pick up a tagged amendment from amending legislation and position it correctly into another provision, within the constraints of the DTD (whether as an insertion or substitution for existing text).

C24. (M) It MUST be possible for an editor to copy a whole amendment provision from an amending document and paste it in the amended document either as a new version of an existing provision or as the first version of a wholly new provision, within the constraints of the DTD.

C25. (D) It SHOULD be possible to perform multiple identical operations within specified provisions to allow the following procedures: entering or changing specified attributes, entering commentary and repealing whole provisions and/ or any combinations of these.

C26. (M) It MUST be possible to show any amendment text in highlighted manner whether in the amending or amended provision.

C27. (HD) It SHOULD be possible to “Undo” any transaction performed in the same terminal session.




C28. (M) It MUST be possible to create, amend or delete editorial commentary relating to a whole item of legislation, to any heading relating to a level of division within the legislation (e.g. Schedule, Part, Chapter), to any provision or sub-provision or to any identified amendment text anywhere in the document.

C29. (M) The system MUST provide a facility to maintain different types of commentary.

C30. (HD) It SHOULD be possible to associate an item of commentary with the location in the text to which it relates.

C31. (HD) It SHOULD be possible to associate one item of commentary with more than one location within a single provision.

C32. (HD) It SHOULD be possible to move directly between an item of commentary and any associated location/or locations in a provision.

C33. (M) It MUST be possible to copy and paste text from Word, Notepad or from within the same document.

C34. (D) It SHOULD be possible to create and maintain a display menu of commonly used or prescribed form of words to insert in commentaries.

C35. (M) One of the “desirable” elements contained within the End User requirement Enquiry service is to enable navigation between the amending and the amended provision. The Supplier MUST provide a proposal detailing the implications for the development of this system in order to meet that specific requirement.

C36. (M) The system MUST provide a spell check facility.

C37. (HD) It SHOULD be possible to add words to the spell check dictionary. C38. (M) It MUST be possible to view images in context within a document structure

that contains a reference to them.

C39. (HD) It SHOULD be possible to enable a facility for an editor to set an optional “autosave” function with variable time delay.

C40. (HD) It SHOULD be possible to enable a facility for the System Manager to set a time-out function (at document level) with variable time delay.

C41. (HD) It SHOULD be possible to resize the presentational view within the window.




Annex D

Data Requirements

D1. Existing System

D1.1 General Overview

D1.1.1 The current system receives and converts documents that are held in SGML format. The conversion process produces Interleaf 5 SGML files and although the original basic structure is retained, Interleaf introduces an additional set of rules based components. Interleaf has also been used to stylise text. It is partly for these reasons that a data extraction and conversion exercise has been undertaken and is fully specified in D2, below.

D1.1.2 The existing system has now reached the end of its life in terms of supporting our current and future business requirements.

D1.2 Data Contents

D1.2.1 The SGML DTD’s used in our current system are attached at Annex H and are applicable to Primary and Secondary legislation.

D1.2.2 Apart from the explicit data fields contained in the DTD, there are also other fields used, particularly in relation to specifying attributes or enriching the base data. The table below records the data field, its purpose, a value range (where appropriate) and identifies the level of application (x = yes).

Name Description Value Range LEX LEVExtent The identification

of the geographical application of the legislation or a provision

“E”, “S”, “W”, “NI”, or any multiple combination of these values

x x

Subject Definition of classification

x

Start Date See 9.2 Annex E x xStop Date See 9.2 Annex E x xConfirs Power See 9.4 Annex E “Y” or “N” xBlanket Amendment

See 9.5 Annex E “Y” or “N” x

Commentary Used to explain the changes to the law and to cross

Authority for text – footnotes (F)

x x




reference to other laws. Added by editors to the Interleaf document.

Extent (E)

In force status (I)

Other qualifications – crossnotes (C)

Power to make subordinate legislation (P)

Other commentary – X notes (X)

Reference – citations (M)

D1.2.3 The DTD also carries the value for the “Lex Type”, denoting the classification

for the document. The current values are in the range:

DESCRIPTION CODE

Act UK Parliament 1801 to date 20100Local or Personal Act UK Parliament 1801 to date 20101Act GB Parliament 1701 - 1800 20200Act English Parliament 1226 - 1707 20300Act Scottish Parliament to 1707 20400Act Scottish Parliament 1999 to date 20401Act Irish Parliament 1495 – 1800 20500Act N. Irish Parliament 1921 – 1972 20600Northern Ireland Assembly Measure 1974 onwards 20700Act Northern Ireland Assembly 2000 to date 20701Measure of the Church Assembly or General Synod 20800Prerogative Instrument 20900Private Act 21000Statutory Instrument (1948 on) 30100Scottish Statutory Instrument 30101Scottish Statutory Instrument (Local) 31001Welsh Statutory Instrument 30102Welsh Statutory Instrument (Local) 31002Statutory Rule and Order (1893 – 1947) 30200Subordinate Instrument (general) pre 1893 30300Statutory Rule (N.I.) 1921 on 30400Subordinate Instrument made under CAM or GSM 30500Subordinate Instrument made under Prerogative Instrument 30600Order in Council (N.I. Temporary Provisions) 1972 – 74 30700Order in Council (NI Act 1974) 30800Order in Council (other) 30900Prerogative Instrument and Royal Proclamations 30901




- made under statutory powerMinisterial Order (not an SI) 30902Local Statutory Instrument 31000Resolution of the House of Commons 31100

D2. Data Extraction and Conversion

D2.1 All the information contained in D2 has been extracted from a document produced, for SPO, by a consultant as part of a separate data extraction and conversion exercise. The objective is to populate a SQL database with data that has been exported from Interleaf and saved in ASCII. The ASCII files have then been converted and saved into a repository of SGML documents. The following information is to identify the structure of the records that will need to be loaded, from the SQL source, onto the new system and to provide a small level of further detail about the current system.

[EXTRACT START]

Output FormatIn the previous documents “Statute Law Database – Project Initiation” and “Statute Law Database – Data Extraction Strategy” we identified the dif-ference between a “single instance” document and a “multiple instance document”. For completeness of the output format specification we will summarise the definition as follows:

Single Instance documentThis is a complete copy of a document as it stood at a particular date in its lifespan and applied to a particular geo-political “extent” (eg: “England & Wales”, “Scotland”). The document is correctly encoded using SGML in accordance with its associated DTD.

Multiple Instance documentEach document in the SLD system has a lifespan that begins either at the SLD “baseline” date of 1st February 1991 or its publication date, whichever is the earliest. Throughout its life the document is subject to changes and revisions that affect the:

textual content, attributes of part or all of the document, structure of the document, geo-political “extent” to which it applies.

The SLD system keeps track of these changes within a “multiple instance document” that embodies all of the discrete single instances of that docu-ment during its lifespan. The SLD system is indirectly capable of generat-ing a single instance copy of a document as it stood on a particular date and applied to a particular extent, from the multiple-instance document.




The two axes used to identify a particular single-instance document are “date” and “extent”. On a given date there may be multiple different in-stances of a particular document each applying to a different “extent”. These are generally known as “parallel versions”.

The SLD multiple instance documents are maintained as Interleaf docu-ments that encode both the SGML structure of the single-instance docu-ments and the multiple-instance structures. The SLD uses a concept of “Lex Element Version” (LEV) to implement multiple-instance documents. The interwoven SGML and LEV structures are maintained by the SPO in the native Interleaf documents using semi-automatic processes. As identi-fied in previous documents, this has probably led to a small amount of structural corruption in the documents.

A core requirement of the replacement SLD system is that it be capable of maintaining all versions of the documents held within the database, and be able to retrieve any single-instance on demand. The requirement does not dictate the mechanism to be used to maintain the document versions. In fact it is unlikely that the replacement system would retain the “Lex Ele-ment Version” method. Consequently this conversion utility will “unpick” the interwoven SGML and LEV structures and represent them in a data-base for ease of access.

The database system will be exclusively concerned with maintaining the version control information and will replace the LEV structures within the Interleaf multiple instance documents. Equipped with a library of access methods, the database will provide a persistent storage repository for mul-tiple version documents identified by the axes “date” and “extent”. It has knowledge of a range of the attributes of the documents it holds but has no understanding of the textual content of the documents.

The conversion utility will decode the SGML information from an Inter-leaf document and convert it to textual tags embedded in their correct pos-ition within the textual content of the document. The utility will make no attempt to check the SGML information for anything other than basic cor-rectness. The text containing the embedded SGML tags will be stored within the textual objects of the database. Subsequent validation of the SGML structure of single-instance documents can be performed after data conversion using third-party parsing utilities that draw upon the single-in-stance document “enumeration” and “retrieval” facilities provided by the database.

Two-tier Output Format DefinitionThe consequence of this approach is that the format of the data produced by the conversion utility can be defined on two levels:

The higher level is the data schema used to represent the information ex-tracted from the “Lex Element Version” structures. Each individual




“LEV” object will have attributes that define the range of dates and ex-tents to which it applies along with an associated text object that contains the textual content and embedded SGML tags (in text form) that are/were in effect.

The lower level is the SGML structure as defined in the appropriate Docu-ment Type Definition (DTD) for the particular type of single-instance doc-ument, of which there are two in the SLD system: “sldact” for PGA’s and other primary legislation, and “sldsi” for “Statutory Instruments” and other secondary legislation.

The Document Type Definitions have been in use for many years and for the purposes of defining the output format of this conversion utility we will use the latest available which are as follows:

“sldact” Version 2.0 revision “ak”

“sldsi” Version 2.01 revision “ab”

Logical Database StructureThe “higher level” structure of information about the documents and their component “Lex Element Versions” are represented in the database design. The structure of the data will mirror the LEV structure used on the existing SLD system but it will be distinct from the SGML structural in-formation, and will be more accessible through the database.

At the LEV level a document can be represented as a hierarchical tree structure with LEV’s at its branch nodes and blocks of text at its “leaves”. The diagram below shows a typical document comprising of a two-level LEV structure of “Parts” containing “Sections”.

Figure 1 - Logical LEV Structure of simple document




Each text block contains the SGML tagging and the textual content of the document and belongs either to a LEV node or the root of the document. The LEV nodes themselves contain attributes that define the date and geo-political extent to which its subordinate text blocks belong.

The example shown in Figure 1 has not been modified since its “start date” of 01/01/1992 therefore there is only one LEV for each “Part” and “Section”. Consider the example in Figure 2 which shows the structure of the same document after section “s.3” was modified with effect from 02/05/1995. There you can see that there are two separate LEVs represent-ing the same section. The first applied from the date 01/01/1992 to 01/05/1995 inclusive and the second took effect thereafter.




Figure 2 - Logical LEV structure of modified document




Our third example in Figure 3 shows the same document after a modifica-tion to “Part I” that came into effect from 13/08/2001. Note that modifica-tions to higher level LEVs only occur after changes of the LEV attributes, such as the geo-political extent, or the text blocks that are direct descend-ants of the LEV. Consequently, the new LEV representing “Part I” has a new text block to represent the modified preamble to the sections but in-herits both of the subordinate LEVs for sections “s.1” and “s.2”. These low-level LEVs have never been modified so they appear under both ver-sions of the higher level LEV for “Part I”.

Figure 3 - Logical LEV structure of further modified document




The Entity Relationship diagram shown in Figure 4 shows how this hier-archical LEV structure can be represented in a relational database.

Figure 4 - Relational model of LEV structure

This relational model omits many of the complex attributes associated with SLD documents in order to clarify the discussion of its representation of LEV structure. The actual implementation would incorporate all of these data items.

The entities are defined as follows:

vii) Entity - DocThis represents the whole document and its many attributes which in this instance have been limited to the “Short Title”, “Year”, “Number” and “Lex Type”. Our example might be “Finance Act”, “1992”, “c.14”, “PGA”. Clearly there is one instance of “Doc” for each statute document.

viii) Entity – LEVThis represents each node in the logical LEV document structure de-scribed earlier in this section. A Lex Element Version (LEV) is the atomic matter of document version control in SLD. Therefore the attributes of “Start Date” and “Extent” describe the two-axes by which a single in-stance of a document is selected. All LEV’s are bound to their parent Doc by the “Doc ID” foreign key.

ix) Entity – LEV LinkThis represents the branches that join LEV “nodes” and Text Block “leaves” to create a hierarchical LEV structure. Each link joins a “Parent LEV” to either a “Child LEV” or a “Text Block”. Each set of LEV Link




instances that share a common “Parent LEV” represent a group of sibling branches related to a particular tree node.

The “Seq No” attribute represents the ordinal position of each branch within its sibling set, where a lower value indicates an earlier position. The purpose of the “Seq No” is to preserve the order of the document ele-ments. A “Seq No” is only guaranteed to be unique within one sibling set and the absolute value of a particular “Seq No” has no significance. For example a “Seq No” of “5” does not imply it is the fifth branch in the sib-ling set. This is shown in the following diagram, where the document from the previous example has been annotated to show the “Seq No” values of the links. Each sibling set has been ringed for clarity.

Figure 5 - Logical LEV structure showing LEV Link "Seq No" values

An implication of this structure is that each document must have a root “Parent LEV”. This is actually a “dummy LEV” that does not really exist in the SLD system but it provides a root for sequencing the first branch of the LEV hierarchy.

x) Entity – Text BlockThis represents a “chunk” of document text, which includes both the con-verted SGML mark-up and the actual textual content of the document. Each “Text Block” is linked to its parent “LEV” by a “LEV Link”.

By definition, there will never be multiple sequential “Text Blocks” in a sibling set. Where there are multiple “Text Blocks” in a sibling set, they will be separated by LEV’s, thereby representing the text that appears be-fore, after and in-between the LEV’s. Furthermore, by definition, a low-level LEV will always have just a single “Text Block” linked to it as there can be no lower level LEV’s to break-up the text contained in the LEV.




xi) Example DatabaseThe following tables show the contents of the database records that repres-ent the example document shown in Figure 5.

Table: Doc

Doc ID

Short Title Year Number Lex Type

1 Finance Act 1992 c.14 PGA

Table: LEV

LEV ID

Doc ID

Start Date

Extent Comment

1 1 01/01/1992

EWS Dummy “root” LEV

2 1 01/01/1992

EWS “Part I” (1992 version)

3 1 01/01/1992

EWS “s.1”

4 1 01/01/1992

EWS “s.2”

5 1 01/01/1992

EWS “Part II”

6 1 01/01/1992

EWS “s.3” (1992 version)

7 1 01/01/1992

EWS “s.4”

8 1 02/05/1995

EWS “s.3” (1995 version)

9 1 13/08/2001

EWS “Part I” (2001 version)




Table: Text Block

Text Block ID

Text Content

1 <sldact><control><ti>Finance Act 1992</ti><actid>……

2 <p><hp>Taxation and Revenue</hp><para>This par……..

3 <d1><n1>s.1</n1><h1>Personal Taxation</h1><t1>……..

4 <d1><n1>s.2</n1><h1>Excise Revenue</h1><t1>……..

5 <p><hp>Interest Rate Policy</hp><para>The futu……..

6 <d1><n1>s.3</n1><h1>Overseas Earnings</h1><t1>……..

7 <d1><n1>s.4</n1><h1>Taxation Strategy</h1><t1>……..

8 </body></sldact>9 <d1><n1>s.3</n1><h1>Offshore Income</

h1><t1>……..10 <p><hp>Taxation and Revenue</hp><para>This

par……..

Table: LEV Link

Parent LEV ID Child LEV ID Text Block ID Seq No

1 <NULL> 1 11 2 <NULL> 72 <NULL> 2 32 3 <NULL> 63 <NULL> 3 12 4 <NULL> 84 <NULL> 4 101 5 <NULL> 135 <NULL> 5 25 6 <NULL> 56 <NULL> 6 15 7 <NULL> 1507 <NULL> 7 3




1 <NULL> 8 225 8 <NULL> 108 <NULL> 9 11 9 <NULL> 99 <NULL> 10 99 3 <NULL> 269 4 <NULL> 31

xii) Physical Database StructureNow that we have explained the concepts behind the database structure, we can add the details specifying all table attributes, data types and phys-ical implementation details.

The database will be implemented under Microsoft SQL Server 2000 on a Windows 2000 Server. The intention is that all data extraction utilities will run on one or more separate workstations, accessing the server over a LAN. This will give best performance and scalability. These are issues that may become important when the full SLD data set is actually extrac-ted.

The SQL definition of the “Document” database is shown in Annex A. This now includes all LEV attributes defined in the SLD system. Note that the document database is one of two databases used by the conversion util-ity, the other being the “Job Control” database. The “Document” database is the one that is of interest to the Supplier of the replacement SLD sys-tem.

The Supplier of the new SLD system will load data from this “Docu-ments” database. They can do this either by using the Persistent Document class methods provided in this utility, or by direct access to the database tables. Both components will be made available to the Supplier as a stand-ard format Microsoft SQL Server 2000 database backup and a code mod-ule on a suitable type of removable media.




DOCUMENT DATABASE DEFINITION – SQL DDL SCRIPTSThis shows a precise definition of the “Documents” database physical structure and at-tributes through the SQL DML scripts that create the database.

CREATE TABLE [dbo].[Doc] (

[Doc ID] [int] IDENTITY (1, 1) NOT NULL ,

[Lex Type Code] [int] NOT NULL ,

[Year] [char] (60) NOT NULL ,

[Number] [char] (20) NOT NULL

) ON [PRIMARY]

GO

CREATE TABLE [dbo].[LEV] (

[LEV ID] [int] IDENTITY (1, 1) NOT NULL ,

[Doc ID] [int] NOT NULL ,

[Lex Element No] [int] NOT NULL ,

[Lex Element Version No] [int] NOT NULL ,

[Extent] [char] (5) NOT NULL ,

[Start Date] [datetime] NOT NULL ,

[Stop Date] [datetime] NULL ,

[Date Last Affected] [datetime] NULL ,

[Blanket Amendment] [binary] (1) NOT NULL ,

[Confers Power] [binary] (1) NOT NULL ,

[Exercise Of Power] [binary] (1) NOT NULL ,

[Duplicate] [binary] (1) NOT NULL ,

[Parent Cmpn Type] [char] (30) NULL ,

[Sif Group] [char] (6) NULL ,

[Sif Group 2] [char] (6) NULL ,







[Subject] [char] (100) NULL ,

[Subject 2] [char] (100) NULL ,




[Commentary Ref] [char] (10) NULL ,

[Num] [char] (10) NULL ,

[Old Commentary Ref] [char] (10) NULL

) ON [PRIMARY]

GO

CREATE TABLE [dbo].[LEV Link] (

[Parent LEV ID] [int] NOT NULL ,

[Child LEV ID] [int] NULL ,

[Text Block ID] [int] NULL ,

[Seq No] [int] NOT NULL

) ON [PRIMARY]

GO

CREATE TABLE [dbo].[Text Block] (

[Text Block ID] [int] IDENTITY (1, 1) NOT NULL ,

[Text Content] [text] NOT NULL

) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]GO

[EXTRACT END]

D3. DATA INPUT

D3.1 The data input for the initial population of the new system has already been described at D2 above.

D3.2 (M) It MUST be possible for the system to record the following information for each document by date:-




(a) Stagevalues “Data Load”

“Initial Edit”“Editorial Revision”“Review”“Published”

(b) Status Within Stagevalues “Warning”

“Error”“Publishable”

(c) Free Text Field For Editorial Comments – this should be an individualrepeating field to enable editors to record new comments and view previous comments.

D3.3 The Stationery Office will continue to provide newly enacted and made legislation for the new system. This will be sent to the SPO by electronic transfer, as an e-mail attachment (zipped), or via CD. Examples of the current XML formats are attached at Annex H, but the Supplier should note that these may be subject to some minor changes prior to implementation.

D3.4 (M) It MUST be possible to load the data in XML format.

D3.5 (M) It MUST be possible to import and export full colour/grey scale and black and white images in .TIF, .GIF, .jpeg and .pdf formats.

D4. Data Output and Reports

D4.1 Data Output

D4.1.1 (M) As stated earlier in this document, it is planned to provide access to the Knowledge Network team to enable the implementation of the transfer of data from the Editorial database to the Enquiry database. The Supplier MUST specify their proposals for meeting this requirement, taking account of the end user requirements included at Annex G. The transport mechanism for the data feed will be defined and agreed with the Knowledge Network team, post award of contract, and will be compliant with e-GIF standards (The e-Government Interoperability Framework is published on WWW.govtalk.gov.uk).

D4.1.2 (M) It MUST be possible, on export of the data, to have included in the header of each document, a correct representation of the appropriate crest/banner relevant to the following classes of document:

UK Crest (Royal Arms)Scottish Crest (Scottish Arms)Welsh Crest (Welsh Arms)Statutory Instrument Banner(Welsh Language) Statutory Instrument Banner




Order in Council BannerStatutory Rule BannerRoyal ProclamationScottish Statutory Instrument BannerArchbishop’s Instrument BannerPrerogative Instrument BannerMinisterial Order BannerLS Seal (Secondary Legislation).

D4.2 Data Take-on Reports

D4.2.1 (M) As a result of the initial data load, there will be a requirement for the System Manager to have access to information concerning the throughput of data. The system MUST generate reports identifying the key values of those records successfully loaded and those that have failed.

D4.2.2 (HD) The reports SHOULD also provide summary details on the number of records processed.

D4.2.3 (HD) For records that have failed the load validation test, then an appropriate error message SHOULD be displayed.

D4.3 Daily Reports

D4.3.1 (D) The System Manager SHOULD have access to a Daily Transaction Report that displays statistics concerning the loading of new legislation.

D4.3.2 (HD) The System Manager SHOULD also have access to statistical information regarding the database (e.g. total number of records by type, database size, available storage).

D4.3.3 The final detail of these reports will be agreed during the early stages of development.

D4.3.4 (HD) The system SHOULD also provide access to a (management) report that provides a record of progress by category (as defined in D 3.2) and by date range.




Annex E

Editorial Overview

1. Introduction

1.1 This overview summarises the legislation held on the database, how it is presented and what editorial information is added.

2. Legislation held on the database

2.1 The database includes (or will, when completed, include) the current revised text of all the primary legislation listed at para. 3.1 below that was either in force at 1.2.1991 (‘the basedate’) or enacted since that date. Historical versions of revised legislation from the basedate to the present are retained. SLD also holds the primary legislation listed at para. 3.2 below and the secondary legislation listed at 4.2 below, but these types of legislation are not at present revised.

3. Primary legislation

3.1 Primary legislation of the following kinds is held on SLD and revised as appropriate:

a) Public General Acts of the United Kingdom Parliament (1801 - date).

b) Acts of the Parliament of Great Britain (1707 - 1800).

c) Acts of the English Parliament (1267 - 1706).

d) Acts of the Scottish Parliament (1424 - 1707).

e) Acts of the Scottish Parliament (1999 – date).

f) Acts of the Irish Parliament (1495 - 1800).

g) Church Measures (1920 - date).

3.2 Primary legislation of the following kinds is held on SLD but is not revised:

a) Local (but not Personal) Acts of the United Kingdom Parliament (mostly 1991 - date).

b) Some instruments made by Royal prerogative (1991 – 1994).

c) Orders in Council made under the Northern Ireland Acts of 1974 and 2000 (1991 - 2000) (anomalously, these constitute primary legislation for Northern




Ireland though in the form of Statutory Instruments, which are secondary legislation –see below).

d) Acts of the Northern Ireland Assembly (2000 – date).

3.3 The basedate text of the primary legislation listed in para. 3.1 above was derived principally from the publication ‘Statutes in Force’ (‘SIF’) supplemented as necessary by text from the Queen’s Printer’s copies. (SIF was a ‘loose-leaf’ style publication containing revised primary legislation presented in groups according to subject matter. Each subject group was kept fully up to date by the issue of cumulative supplements as required until next reissued with the revisions consolidated. In preparation for the start of work on SLD, the text of SIF was fully revised, either by reissues or cumulative supplements, to the SLD basedate.)

3.4 All primary legislation passed since the basedate is included except that there are no Personal Acts and the only prerogative instruments included are those printed in the official editions of delegated legislation from 1991 to 1994. The text of post-basedate legislation is supplied in electronic form by The Stationery Office Ltd (‘TSO’).

4. Secondary legislation

4.1 The secondary legislation held on SLD is general legislation made since 1.1.1991 under powers conferred by primary legislation listed above. For practical purposes this consists of all instruments printed in the official series of subordinate legislation, supplied in electronic form by TSO.

4.2 Secondary legislation of the following kinds is included (all 1991 – date):

a) Statutory Instruments (‘S.Is.’) (made under powers contained in UK Acts and include instruments made by the new Welsh Assembly).

b) Scottish Statutory Instruments (‘S.S.Is.) (from 1999 only, made under powers contained in Acts of the Scottish Parliament).

c) Statutory Rules of Northern Ireland (‘S.Rs.’) (made under powers contained in Northern Ireland Orders in Council and Acts of the Northern Ireland Assembly).

d) Archbishops’ Instruments (made under powers contained in Church Measures).

5. Citation of Legislation

5.1 An Act of Parliament dating from 1963 or later may be cited by reference to:

a) Its short title (e.g. Common Land (Rectification of Registers) Act 1989); and




b) Its year and chapter number (here, 1989 c.18).

These are unique references. Where the original short title is effectively changed by a later Act (e.g. the Capital Transfer Tax Act 1984 (c.51) was rechristened the Inheritance Tax Act 1984 by s.100(l) of the Finance Act 1986 (c.41)), both the original short title and the new one will be valid ways of referring to the Act in question.

5.2 An Act of Parliament from before 1963 may be cited by reference to:

a) Its short title (e.g. the Inclosure Act 1848), whether the short title was given by the Act itself or by a later enactment (in this case the Short Titles Act 1896).

b) The Parliamentary Session and chapter number (here, 1]. & 12 Vict. c.99). The Session is indicated by the regnal year(s) during which it ran. In the case of a regnal year with more than one Session, the Session number will also be part of the reference for the second Session (e.g. there were two Parliamentary Sessions in the first year of Queen Anne: 1 Ann c.1 is the Crown Lands Act 1702 (still in force), and 1 Ann. St.2 c.1 is the Land Tax Act 1702 (repealed)).

c) The calendar year and chapter number (here, 1848 c.99). The calendar year is that in the short title and the chapter number is that given by reference to the regnal year. This form of reference is a convenient shorthand, though strictly illogical.

6. Presentation of Amendment Text in Amending Provision

6.1 Amendment text contained within an amending provision is normally, but not always, enclosed within quotation marks in the Queen’s Printer’s copy and on SLD. When carrying through a textual amendment the Editor identifies the relevant amendment text and applies it to the amended document, see para. 7.1 below. Amendment text may itself be contained within a block of amendment text. This is known as a ‘nested amendment’.

7. Presentation of Revised Text

7.1 As far as possible, the visual presentation of the text of legislation on SLD follows that of the Queen’s Printer’s copy. Amendments applied to the text are defined by square brackets and repeals of text shown by rows of dots. (Authority for these amendments and repeals, as well as for other effects, which do not alter the text and certain other editorial information, is given by way of footnote commentary - see below). There are certain requirements, however, that call for special presentational solutions:

7.2 Successive Versions of Provisions

A whole Act, Statutory Instrument or other piece of legislation is referred to in




the SLD jargon (which will be used here, with apologies, for convenience) as a ‘lex’ (‘lex’ being Latin for a law, plural ‘leges’). Each provision (e.g. section of an Act, paragraph of a Schedule, article of an S.I., etc.) or other distinct element of legislative text is called a ‘lex element’. Those parts of a lex which occupy distinct lex elements include the formal parts at the beginning (short title, year and chapter number, preamble, long title, Royal Assent date, words of enactment, in the case of Acts, and the corresponding items in other legislation) and all headings (e.g. Schedule headings, Part headings, italic cross-headings, etc.). Whenever there is a change to the text (and in certain other circumstances) a new version of the lex element is created containing those changes whilst the earlier version or versions remain accessible for historical information. Each version of the lex element is known as a ‘lex element version’ (or ‘lev’, for short). The first version will always show the lex element in the form in which it was enacted (or, in the case of a pre-basedate lex, the form in which it had effect at the basedate) and the text will not usually be altered except to correct errors.

7.3 Prospective Versions

Where the text of a lex element is amended but the amendments (or any of them) have not yet been brought into force (i.e. are ‘prospective’), a separate lev is made, in addition to the current lev, showing how the lex element will appear when the prospective amendments are in force.

7.4 Concurrent Versions

In certain circumstances, it is necessary to have two or more current versions of a lex element running in parallel. So, for example, where a section of an Act is amended, but only in relation to part of its geographical extent (e.g. a substitution of words is made in a section that extends to the whole of the UK, but the substitution applies only insofar as the section extends to Scotland) or where it is amended only in relation to a specified period (e.g. two conflicting amendments, each of which continues in force indefinitely, relate only to the tax years 1997/98 and 1998/99 respectively), concurrent versions will be needed.

8. Commentary

Commentary is required to record the authority for amendments and also for certain other purposes set out below. Commentary may be associated with any level of the lex, e.g. whole Act, whole Part, whole Schedule, provision, sub-provision or any selected word or words in any text element.

8.1 Textual Amendments (‘F-notes’)

The effect of textual amendments is shown in the text: by square brackets (for insertions, substitutions or where text has ceased to have effect); by three dots (for omissions and repeals of words); or rows of dots (for omissions and repeals of whole provisions or sub-provisions). The commentary will contain a brief description of the type of amendment, the commencement date (or ‘prosp.’ if not yet in force), and a citation of the legislative provisions providing authority for the amendment.




8.2 Non-Textual Amendments (‘C-notes’)

This term is used to denote the effect when the meaning or scope of an Act or any part of it is changed, but without altering the text. The content of the commentary will be similar to that for textual amendments.

8.3 Extent Information (‘E-notes’)

The commentary contains information about the geographic extent of the Act or relevant part of it.

8.4 In Force Status (‘I-notes’)

The commentary contains information about the coming into force of the provision, i.e. whether it is partly or wholly in force, the date or dates of commencement and citing relevant provisions of the Act and any commencing instrument.

8.5 Cautionary Notes and Editorial Comment (‘X-notes’)

X-note commentary alerts the user to anything he may need to be aware of in using the text. These notes have often been used to highlight difficulties arising from pre-SLD editorial practice. For example, certain pre-1922 Acts extending to Ireland used not to be revised insofar as they extended there. These Acts carry X-notes against the long title cautioning that: “This Act is not necessarily in the form in which it has effect in Northern Ireland”.

8.6 Exercises of Powers to make Instruments (‘P-notes’)

Where a provision of primary legislation confers power to make subordinate legislation, ‘attribute’ information will show that such power is conferred (see below). When that power is exercised (i.e. an instrument is made in pursuance of it), that exercise may be recorded in P-note commentary. The commentary need consist only of the citations of any instrument made under that power.

9. Attribute Information

9.1 General

In addition to the information provided by commentary, there are items of information appended to each lex element version, and to the whole Act, described on SLD as ‘attributes’. Although attributes provide some information about the provision to which they are attached, or to that version of it, they must be treated with some care because they may lack the precision of commentary and should not be regarded as equivalent to, or as a substitute for, commentary. For instance, a ‘start date’ represents the earliest date on which a particular version of a provision had effect, but it does not mean that it was wholly in force in that form on that date. The relevant amendments may have come into force for certain purposes only on the earlier date and for other purposes on a later date and the user must look to the commentary for the detailed information. Further, the ‘start date’ may or may not also represent the earliest date on which




the provision itself, as it was enacted, came into force. Once again, the attribute is inadequate as information without further enquiry.

9.2 Start and Stop Dates

The ‘start date’ indicates the earliest date on which a lev had effect in that form and the ‘stop date’ the last date on which it had effect in that form or the day before it was superseded by a new version coming at least partly into effect. In the current published version of SLD, these attributes determine the version(s) of a lex element produced by a search against a specified date.

9.3 Extent

A lex element version may apply to the whole of the United Kingdom or only to certain jurisdictions or geographical areas (i.e. England, Wales, Scotland, Northern Ireland or any combination of these). In the current published version of SLD, this attribute determines the version(s) of a lex element produced by a search against a specified extent.

9.4 Power to Make Subordinate Legislation

This attribute consists of a simple Yes/No indication of whether the provision contains any power to make subordinate legislation. It relates to the ‘P-note’ commentary field mentioned above. In the current published version of SLD, this attribute is used to facilitate searches for provisions containing such a power.

9.5 Blanket Amendments

This is an indication whether the provision contains any amendments affecting legislation generally (e.g. “references...in any enactment...to youth courts shall be construed as references to juvenile courts”). In the current published version of SLD, this attribute is used to facilitate searches for provisions blanket amendments.




Annex F

Examples of Legislation

Example 1 Public General Act of Parliament

Example 2 Within a Public General Act of Parliament

2A An Arrangement of Sections2B Part Headings, Crossheadings and Sidenotes

Example 3 Statutory Instrument

Example 4 Amending Provision – inserting/substituting a subsection

Example 5 Amended Provisions

5A Repeal of a whole Section5B Repeal of a Subsection5C Repeal of Words5D Substitution of a Subsection5E Substitution of Words

Example 6 Nested Amendment

Example 7 Interleaf Copy – Different types of Commentary

Example 8 Welsh Statutory Instrument.




Annex G – FOR INFORMATION PURPOSES ONLY

Functional Requirement for the Enquiry System

1. Introduction

1.1 The primary objective of the project is to ensure the successful implementation of a new editorial system for SLD within the Statutory Publications Office (‘SPO’). The secondary objective (with which the Specification for the Enquiry System is concerned and which is dependent on progress towards the implementation of the primary objective) is to ensure the successful implementation of the related enquiry system (i.e. to meet all of the mandatory requirements and some or all of the desirable requirements contained in that Specification). This Annex contains the functional requirements laid out in the Specification for the Enquiry System.

1.2 The enquiry system will be built and hosted by the Knowledge Network (branded for public access as ‘UK Online’ and available to government users through the Legal Information On-line network (‘LION’)). Although the provision of the enquiry system is not the subject of competitive tendering, it is understood that the Knowledge Network (‘the Supplier’) will, at the appropriate time or times (which timing may depend on progress with the primary objective of the project), specify their proposals for the enquiry system. The Supplier of the replacement SLD system need to ensure that the proposals conform with the accreditation of the Knowledge Network Infrastructure. SPO undertakes to comply with the Knowledge Network Code of Connection.

2. Mandatory Functional Requirements

2.1 The enquiry system MUST comply with e-GIF (e-Government Interoperability Framework published 1st May 2002) and the Guidelines for UK Government Websites – Illustrated Handbook for Web Management Teams (published May 2002), where relevant.

2.2 It MUST be possible for the end user to identify the Website being accessed and its purpose.

2.3 It MUST be possible for the end user to view updateable information and messages or items of news regarding the database. This must include a Crown Copyright statement and a disclaimer about misuse of the site.

2.4 It MUST be possible for the end user to establish how up to date the editorial content of the database is.




2.5 There MUST be a facility for the end user to give feedback about the database to the Statutory Publications Office and/ or Knowledge Network.

2.6 It MUST be possible for the end user to search the system for required documents using appropriate search criteria. Typically these would include: year and chapter numbers of Acts, Statutory Instrument number, title (or the corresponding elements for all legislation carried on SLD) geographical extent, operative dates and word and phrase searches.

2.7 It MUST be possible for the end user to view the result of a search and to identify the best matches to the search criteria.

2.8 It MUST be possible for the end user to view entire items of legislation.

2.9 The appearance of the document, to the end user, MUST be broadly consistent with that of the Queen’s Printer’s hard copy, including any tables and images.

2.10 It MUST be possible for the end user to view an item of legislation as it stood when it was enacted (or as it stood at the base date of 1.2.1991 if that is later).

2.11 It MUST be possible for the end user to track and view a whole document and any provision as it stood on a particular date.

2.12 It MUST be possible for the end user to view a ‘content list’ of provisions in an item of legislation and to move from that list to any selected provision in a single operation.

2.13 It MUST be possible for the end user to navigate entire items of legislation. Typically this will include scrolling, page specification, provision number specification and word and phrase searches. In carrying out word or phrase searches, any markers or embedded codes in the text SHOULD be ignored.

2.14 It MUST be possible for the end user to identify, where applicable, that a provision has more than one version.

2.15 It MUST be possible for the end user, where applicable, to be able to identify and view successive versions of a provision. [See Annex E para. 7.2]

2.16 It MUST be possible for the end user, where applicable, to be able to identify and view concurrent versions of a provision. [See Annex E para. 7.4]

2.17 It MUST be possible for the end user, where applicable, to be able to identify and view prospective versions of a provision. [See Annx E para. 7.3]

2.18 It MUST be possible for the end user to view “start dates” and “end dates” attributed to the whole document and to each version of any provision. [See Annex E paras. 9.1, 9.2]

2.19 It MUST be possible for the end user to view the basic geographical extent attributed for search purposes to the whole document and to each version of any provision. [See Annex E para. 9.1, 9.3]




2.20 It MUST be possible for the end user to identify provisions that make ‘blanket amendments’. [See Annex E paras. 9.1, 9.5]

2.21 It MUST be possible for the end user to identify provisions that confer power to make subordinate legislation. [See Annex E paras 9.1, 9.4]

2.22 It MUST be possible for the end user to ascertain whether any power to make subordinate legislation conferred by a provision has been exercised.

2.23 It MUST be possible for the end user to identify clearly amendments to text and repeals of text in any provision or other part of the document so amended, including insertion, substitution and repeal of whole provisions, headings etc. (See also related entry at 3.7 below).

2.24 It MUST be possible for the end user to view added editorial information (‘commentary’) relating to a whole item of legislation, to any heading relating to a level of division within the legislation (e.g. Schedule, Part, Chapter), to any provision or sub-provision or to any identified amendment text anywhere in the document and to move between that commentary and the level or location within the document or provision to which it relates. (See also related entry at 3.4 below) [See Annex E – whole of para. 8]

2.25 The system MUST provide the end user with a printer-friendly version of the document.

2.26 It MUST be possible for the end user to return to the last page or document viewed in one single operation. (See also related entry at 3.6 below).

2.27 It MUST be possible for the end user to copy selected text for pasting to other applications (with or without embedded codes or footnotes, or the equivalent method adopted for displaying editorial information).

3. Desirable Functional Requirements

3.1 It would be HIGHLY DESIRABLE for the end user to be able to identify clearly any reference in commentary (appearing in a prescribed format) to an item of legislation and any operative provision or sub-provision of that legislation (e.g. ‘2002 c. 15, s. 138(2)’ or ‘S.S.I. 2002/335, reg. 2(3)’) and to move between that reference and the legislation/provision/sub-provision to which it refers. [e.g. an editorially defined hyperlink to amending legislation. This ‘highly desirable’ requirement will apply only to references in commentary inserted after the new SLD system is operational. See also related entry at 3.2 below].

3.2 It would be HIGHLY DESIRABLE for the end user to be able to identify clearly any reference in an item of legislation (whether in commentary or in the text of the legislation) to another item of legislation (e.g. ‘2001 (asp 10)’, ‘S.I. 1999/646’) and to move between that reference and the item of legislation to which it refers (provided that item of legislation is carried on the database). [A more limited form of cross referenced navigation than envisaged by entry 2.2.1 above and might be used to give access to whole items legislation from




references in the body of the text of a document or in commentary inserted before the new SLD system became operational using a technology such as J-links].

3.3 It would be HIGHLY DESIRABLE for the end user to be able to save documents accessed for viewing at another time.

3.4 It would be HIGHLY DESIRABLE for the end user to be able to distinguish between different types of commentary (e.g. commentary relating to: textual amendments; non-textual modifications; commencement information; extent information, etc.). (See entry 2.24 above) [See Annex E – whole of para. 8]

3.5 It would be DESIRABLE for the end user to be able to view more than one item of legislation at the same time.

3.6 It would be DESIRABLE for the end user to be able to track the last 10 pages or documents viewed.

3.7 It would be DESIRABLE for the end user to be able to identify clearly amendment text as it appears in the amending provision (and to distinguish it from amendment text as it appears in the provision amended – see entry 2.23 above).

3.8 It would be DESIRABLE for the end user to be able, when viewing a specific provision, to view simultaneously any headings relating to that provision (e.g. Schedule heading, Part heading, Chapter heading, italic cross-heading) whether or not those headings immediately precede that provision, and also to view the title and number of the item of legislation.

3.9 It would be DESIRABLE for the end user to be able to view a list of all items of legislation of any specified type carried on SLD (arranged, at the user’s option, either alphabetically or chronologically) and to access from such list any selected item of legislation.




Annex H

SGML and XML DTDs

