OASIS Legal XML

Electronic Court Filing Technical Committee

Face to Face Meeting

Seattle, Washington

September 16, 2005

Attendance – Voting Member / Member / Observer

Name / Last Name / Present[(]
Allen Jensen (Orange County Superior Court) – Member / Jensen / *X
Ann Dillon (Washington AOC) – Observer / Dillon
Ann Sweeney (Washington AOC) – Observer / Sweeney
Brad Midstokke (Sierra Systems) – Member / Midstokke
Catherine Plummer (SEARCH Group, Inc.) – Member / Plummer
Brian Hickman (Wolters Kluwer) / Hickman / X
Charles Gilliam (ContentGuard) – Observer / Gilliam
Chet Ensign (Reed Elsevier) – Observer / Ensign
Christopher (Shane) Durham (Reed Elsevier) –Member / Durham / X
Chris Reeve (MTG) (Observer) / Reeve / X
Christopher Smith (California AOC) – Member / Smith
D. Welsh (Microsoft Corporation) – Observer / Welsh
Dallas Powell (Individual) – Member / Powell / X
Dan O’Day (Thomson Corporation) – Observer / O’Day
Dan Sawka (Washington AOC) – Observer / Sawka
David Goodwin (Maricopa County) – Member / Goodwin
David Roth (Thomson Corporation) – Member / Roth
Donald Bergeron (Reed Elsevier) – Member / Bergeron
Ellen Perry (MTG Management Consultants) – Observer / Perry
Eric Tingom (Individual) – Prospective Member / Tingom
Franklin Hagler (Individual) – Observer / Hagler
Gary Poindexter (Individual) – Member / Poindexter
James Cabral (MTG Management Consultants) – Member / Cabral / X
James Cusick (Wolters Kluwer) – Member / Cusick / X
Jamie Clark – OASIS – Staff / Clark
Jason Harrop (Individual) – Observer / Harrop
Jed Alpert (Wolters Kluwer) – Member / Alpert
Jeff Barlow (Oregon Judicial Department) Observer / Barlow / X
Jeff Karotkin (Individual) – Observer / Karotkin
Jim Beard (Individual) – Member / Beard / *X
Jim Clark (Microsoft Corporation) – Observer / Clark
Jim Harris (Individual) – Member / Harris / X
John Aerts (LA County Information) – Observer / Aerts
John Greacen, Co-Chair (Individual) – Member / Greacen / X
John Messing (Law-On-Line, American Bar Association) – Member / Messing
John Ruegg (LA County Information Systems Advisory Body) – Member / Ruegg
Larry Webster (SEARCH Group, Inc.) – Observer / Webster
Laurence Leff (Individual) – Secretary / Leff / *X
Mark Oldenburg – Washington AOC - Observer / Oldenburg
Mark Slosberg (Sierra Systems) -- Observer / Slosberg
Mike Waite (US Department of Justice) – Observer / Waite
Nancy Rutter (Maricopa County) – Observer / Rutter
Nick Pope (Individual) – Member / Pope
Ockert Cameron (Individual) – Observer / Cameron
Pieter Kasselman (Cybertrust) – Observer / Kasselman
Rex Brooks (HumanMarkup.org, Inc.) – Observer / Brooks
Rex McElrath (Judicial Council of Georgia) – Member / McElrath / X
Richard Baker (Judicial Council of Georgia) –Member / Baker
Robert DeFilippis (Individual) – Member / DeFilippis
Robert March (Individual) – Member / March
Robert O’Brien (Individual) – Member / O’Brien / X
Robin Cover – OASIS – Observer / Cover
Robin Gibson, Secretary (Missouri AOC) – Member / Gibson / X
Rockie Morgan (Sierra Systems) – Member / Morgan
Roger Martin (AOL) – Observer / Martin
Roger Winters, Editor, Representative to Member Section Steering Committee (Washington AOC, King County) – Member / Winters / X
Rolly Chambers (Individual) – Member / Chambers / *X
Scott Came (Individual) – Voting Member / Came / X
Scott Edson (LA County Information Systems Advisory Body) – Member / Edson
Scott Schumacher (Thomson Corporation) – Observer / Schumacher
Shogan Naidoo (Individual) - Member / Naidoo / *X
Steven Fiore (Sierra Systems) – Observer / Fiore
Steven Taylor (Individual) – Observer / Taylor
Terry Bousquin (Individual) – Member / Bousquin / X
Todd Marsh (Sierra Systems) – Observer / Marsh
Tom Carlson (National Center for State Courts) – Member / Carlson / X
Tom Clarke, Co-Chair (National Center for State Courts) / Clarke / X
Tom Smith (Individual) – Member / Smith
Tony Rutkowski (Verisign) – Observer / Rutkowski
Winfield Wagner (Crossflo Systems Inc.) – Observer / Wagner

Decisions

1. The TC will develop a non-normative “tourist guide” for the ECF 3.0 specification. Roger Winters and Terrie Bousquin will be responsible for preparing the document.

2. We will use the term “case category” to refer to the case specific information included in ECF 3.0.

3. Courts will define the case types that they use in Court Policy. We will make no effort to incorporate the case type taxonomy from the NCSC Statistical Guide in ECF 3.0.

4. We will use the OASIS website as the repository for the normative version of the specification, schemas and other artifacts.

5. We will not recommend any standard for archiving electronic filing messages.

6. We will change the cardinality of language for a document from one to many. Robert O’Brien will investigate how Europe handles references to document languages to see whether the domain model needs to be expanded.

7. We will include an element in document metadata that indicates that color is or is not relevant for the presentation of a document.

8. We will include a “special handling” element in document metadata to provide any additional instructions for printing of a document (such as printing on front and back of the same page or printing on a particular color paper).

9. We will use the term “attachment” only as a technical term, not as a synonym for exhibit.

10. We will use the term “connected document” (rather than “supporting document”) to refer to a document that does not stand on its own.

11. A signature can be embedded in a document or included in a separate attachment.

12. The specification will provide two ways to sign a document divided into parts because of file size limitations

a. Applying a signature to each part of the document (which can then be read as individual documents).

b. After the signature is applied to the document, slicing the document digitally into multiple parts (which can be read only when the document is reassembled into a single document by the court).

All courts must support the latter method. Courts will indicate within their Court Policy whether they support the former.

13. ECF 3.0 will not support simultaneous versions of the same document.

14. ECF 3.0 will support only one level of connected documents; the message structure does not include a nesting function.

15. The ECF 3.0 specification will include a glossary of key elements.

16. The ECF 3.0 specification will not include the semantics of the domain model and element definitions.

17. The ECF 3.0 specification will include an architecture section.

18. The ECF 3.0 specification will include an explicit discussion of the GJXDM, including ECF 3.0’s approach to extending ECF 3.0 schemas.

19. The ECF 3.0 specification will include an introductory discussion of its scope.

20. ECF 3.0 will support multiple signature profiles, including

None

A signature image embedded in the document

An XML signature

Some combination of user ID, password, and PIN

A digital signature

21. The domain model will be modified to add additional document metadata elements – signature profile URI and signature information (any type).

22. The ECF 3.0 specification will require that once an MDE supports a signature profile, it must maintain its support of that profile.

23. Digital signatures can be embedded within documents when they are enclosed as attachments or included as separate attachments.

24.. WSI Security provides for a digital signature for an entire message to be carried in the SOAP header.

25. The SOAP header identifies what is encrypted. Scott Came will verify that encryption can apply to information contained in a separate argument. If so, he will make sure that payment information exists as a separate argument. Attachments are separate arguments, so a particular document can be encrypted.

26. ECF 3.0 will disaggregate the Query MDE so that each query is defined as directed at a specific MDE.

27. Scott Came and Shane Durham will review the use of the term MDE and ensure that it is used appropriately and consistently throughout ECF 3.0.

28. The members present rejected Shane Durham’s request to disaggregate the Court Policy MDE.

29. Roger Winters will propose alternative language for the phrase “physical document.”

30. Shane, Jim Harris, John Greacen, and Jim Cabral (and others who wish to participate) will revise and expand the domain model for case query to create a structure for reporting case docket information in XML form. This process will be conducted using Don Bergeron’s web meeting facility.

31. John Greacen will request an extension of the delivery date for ECF 3.0 to November 1

32. John and Tom Clarke will set a series of deadlines for commenting on parts of the specification and other artifacts. Failure to comment will constitute consent to the TC’s adoption of the artifact in its current form.

33. John, Tom, Jim and Scott will develop a statement of work for an MTG technical support contract and seek Member Section Steering Committee and OASIS approval of it.

34. The ECF 3.0 specification should state whether the standard supports the exchange among lawyers of documents not intended for filing in a case.

35. The ECF 3.0 specification should state the extent to which filings include the metadata required for a formal case caption.

The day began with a formative meeting of the Court Documents Subcommittee. Following that meeting, the Court Filing Technical Committee convened at 11:00 am.

Review of 3.0 Specification

Eric Tingom posted the filing specification a few days ago; it is a 136 page document labeled “Working Draft 04, September 9, 2005.” John asked whether attendees had read the document. Some have skimmed the document. Some have reviewed it in depth. Some have not begun to review it.

The specification is intended to be a technical document for technical implementers. Roger Winters said we need to create something that is a narrative for lay people explaining the meaning of the specification, how it is used, and perhaps how it might figure in court RFPs and such. Tom Clarke said this sort of document does not necessarily need to be part of the specification.

John Greacen said he wrote a GIEPD (GJXDM Information Exchange Package Documentation) that uses less formal language for the Joint Technology Committee. This could be a starting point for that kind of introductory document Roger advocates. Tom Clarke said he got comments indicating that the technical level of the draft GIEPD was is too high for the Joint Tech audience.

In early days of ebXML they put out a guide to the ebXML architecture, a “tourist-level” guide. Tom suggested this might be a model for the document we are envisioning.

The members agreed to the preparation of a “non normative” executive summary. This document will be distinct from the IEPD. Roger and Terrie Bousquin volunteered to prepare the document.

Jim Cusick praised the draft specification: “It needs an executive summary, but it is a good piece of work. It reads well, and is an implementable specification, with enough detail that one could actually use it to make progress in building something. It has come a long way in the last few months.”

The members present constructed the following list of issues for discussion over the next two days.

Agenda for Review

·  Signatures

o  Are electronic signatures carried in the message, payload, or both?

·  Case types

o  How to handle

·  # of MDEs (Major Design Elements) defined

o  Is there a single query MDE or does each MDE have its own query function?

o  Is there a single Court Policy MDE or does each MDE have its own policy function?

·  Extensions

o  Approach to extensions is not included in the draft specification

·  Is Court Policy to be defined in the specification document?

·  Repository

o  Where does this specification and its artifacts reside?

·  Archiving Messages

o  Pg 13: Issue about archival storage of the artifacts generated out of the document (advice about how they save the messages that are sent to them)

·  Schemas, WSDLs, and web services message profiles.

·  Cardinality of document language.

·  What about documents that need to be viewed in color (colour)?

·  A clear distinction is needed between “attachment” and “supporting document.”

·  Where do we go next? (Tomorrow)

Issue: Number of MDEs and Handling Policy

In the current specification, MDEs are defined on page 6. It says there are five and lists seven. The problem came from listing “Policy MDE” and “Query MDE.” Shane posited that each MDE must have its own query and policy interfaces and rules.

When Shane raised this on the List, the subcommittee considered it and disagreed. It felt that Court Policy is intended as a set of business rules established by the court. The policies that a filing assembly MDE imposes on its users is not within the scope of ECF 3.0. Shane argued these are rules imposed not just on users but also on other components that interact with an MDE.

The group discussed the possibility of having policies identified in a single place, with policies applicable to a particular MDE grouped in a subsection within the general listing of policies. Shane said this was not his choice but that it would be better than the approach in the current draft.

No consensus emerged from the discussion. The topic was tabled for conclusion tomorrow, when Scott Came will be able to participate.