[legalxml-courtfiling] ebXML liaison Report One

["Dr. Laurence Leff" <D-Leff@wiu.edu>]

                                  Report One
                           From the liaison to ebXML
              from the Electronic Court Filing Technical Committee

1. Introduction to ebXML and related Standards efforts

ebXML contains several standards of interest to the Electronic Court Filing
Technical Committee.  It has a messaging standard.  This is built on top
of the Simple Object Access Protocol (SOAP).  The Business Process Specification
(BPS) standard specifies the documents exchanged between parties to 
complete a result, e. g. completing a purchase of goods.  It does this in terms
of roles such as "buyer" and "seller."  Two parties complete a Collaboration
Protocol Agreement (CPA)which specifies parameters for their communication
such as protocols, security arrangements, and the certificates that might
be used to electronically sign their messages.  
It also specifies the roles they will serve in the BPS. [1]
Although, ebXML assumes one CPA for each pair of communicants, it also
provides for Collaboration Protocol Profiles (CPP) discussed below.

The Registry Information Model and Services standards specify techniques by 
which information such as DTD's can be served to the outside world.  
The registry services specification defines a computer interface 
by which "objects" can be submitted to the registry, approved by a responsible 
party and made available to those searching for them. [1] [9]

A related effort is the Universal Business Language (UBL).  This technical 
committee, within Oasis, is developing standards for XML to be exchanged 
between businesses.  They are starting with the Common Business Language (CBL) 
which focuses on documents in the sale of goods such as purchase orders, 
purchase order acknowledgments and invoices.  CBL is a standard made 
available by Commerce One, a large vendor in the B2B space.  However, UBL 
is not limiting their scope to these business situations.

My report shows how some of the features in our deliverables can be done
using these technology.  I particularly focus on the Court Filing 1.1 proposed
specification and electronic filing management-case management system API.

2. Messaging and Information Transfer

As mentioned before, ebXML contains a messaging service standard (ebXML mss).
This standard provides for a message header and a payload.   The Message
services include a multihop transmission, reliable messages, and services to
get the status of messages already sent.  The multihop transmission is between
entities termed Message Service Handler's (msh).  ebxml mss specifies
in detail how routing, and acknowledgments, and trace headers are handled
by the msh's. [1]

In contrast, the electronic Court Filing 1.1 proposed standard [4]
provides that a receiving document can throw out the "encapsulation" and keep
the section enclosed in the "legal" tag.  The "legalEnvelope" tag
is comparable to the ebXML messaging standard header.  

Both ebXML Messaging [9] and our eFiling standard [4] provide for a "from" and 
"to" element in the header.  They only contain a party with a partyID id
which refers to the Collaboration Protocol Agreement (CPA).  The CPA 
contains a pointer to other information.  The CPA is flexible as to the form
of this pointer, but it usually is a DUNS number or a URL.  Of
course, these may refer to contact information such as phone 
numbers or letters--however, these are not specified in any of the
ebXML documents.  
      
However, our electronic court filing provides these elements with information 
on the postal address, electronic mail address, fax number, etc.
(Note: the ebXML message "from" and "to" section can contain one or more
party elements.  Each of these should refer to the same physical
entity.  One could conceivably use one for an email address,
one for a fax number, etc.  However, that appears to be stretching
the intent of the standard.)

The ebXML message specification [3] provides a message with multiple 
attachments.  There is no hierarchical structure.  However, the ebXML
message can have a "Manifest" which is a list of the attachments, their ID's,
and the name of the XML schema that describes them.  

On the other hand, our court filing standard provides several levels.
A single document could have several filings, each with several
documents.  And each document can have several attachments.  In ebXML, there
is no parallel for a message having several payloads, each with its
own attachments.

ebXML allows the users many options in configuring their communication
protocol.  This is specified in the Collaboration Protocol Agreement
between the two parties exchanging messages [9].  

For example, it might require that the ebXML messages 
  a) use a particular digital Certificate for signatures and that all
     messages from or to a party be digitally signed.
  b) use a particular communication protocol to send the messages such as
     http, ftp, or electronic mail.
  c) have a synchronous reply.  This can be a business signal
     or be an XML file containing a result.  This means that the communication
     line remains open until the response is returned to the originator.
  d) each message will be acknowledged, and further, it can specify that the
     acknowledgments be digitally signed.
  e) the message can be encrypted to ensure confidentiality.

The ebXML messaging standard specifies how these requirements are reflected
in the message headers.

The Court Filing standard specifies response types.  The response includes
a time stamp, as does the ebXML messages.  It also allows the court to indicate
acknowledgment, both of the message and whether the item is docketed.  The
court could indicate that the lead document was accepted but that one or more
attachments was not accepted.

The ebXML reliable messaging and acknowledgment protocol could ensure
that the message was sent.  However, a higher level ebXML message
would be needed to return information as to which documents and attachments
was accepted or rejected by the court.

Note that the ebXML Business Process Specification [9] indicates at a higher
level which messages are followed by which messages.  For example, the
Business Process Specification could specify a "collaboration" called
"file lawsuit."  It would consist of a transaction where a party in the
"role" of litigant issued a lawsuit which MUST be followed by the
party in the "role" of court returning a specific XML response document.
The Business Process Specification includes the URL of the schema
definition for each of these entities.  Similarly, the Business Process
Specification would specify that the party in the role of "litigant" could
submit a query document to an entity in the role of "court" and would expect 
a response obeying a particular XML schema.

The EFM-CMS Interface Requirements [10] describe how a piece of software
receives filings from litigants, attorneys, and judges through an
electronic filing service provider.  These are sent to an electronic
filing manager which submits them to the case management system.  Many of 
the features of this architecture can be implemented on top of ebXML 
messaging.   The architecture envisions several computers, the filer, 
the electronic filing service provider, the electronic filing manager, 
and that which is running the case management systems.  The Message Service 
Handling allows for multi-hop messages and acknowledgments that flow back along
the path taken by the original message.  Thus a filing flowing through the 
steps could be treated as a multi-hop message with the efm and efsp 
being Message Service Handlers (msh's).

The EFM-CMS Interface Requirements document describes communication between
the Electronic Filing Manager and the Case Management System.  As electronic
filings arrive at the court, software must receive them and make them available
to the legacy products that the courts currently use.  By providing a standard
interface, vendors of court Case Management System products only have to provide
one interface.  Providers of Electronic Filing Manager software don't have to
write an interface for each of the many Case Management Systems available.

The EFM-CMS SubCommittee envisions standardized calls being used with 
parameters.  These could be Java method calls.  The SubCommittee envisions 
specifying them as Unified Modelling Language messages--which could be mapped
to the programming language of choice.  However, SOAP and ebXML messaging
also envisions each message corresponding to a method call, remotely made over 
the communication protocol.  Thus ebXML can be used to map the UML to
communications between software entities.

2.1 The Collaboration Protocol Profile

As mentioned earlier, there is one Collaboration Protocol Agreement for
every two parties that exchange ebXML messages.  Assume a court allows 
litigants to file directly.   As ebXML is currently structured, each court
will have to prepare a CPA with each filer.  However, the CPA 
standard also includes a Collaboration Protocol Profile (CPP), a prototype
for filling out a specific Collaboration Protocol Agreement between
two parties [2].  The court would prepare a generic (CPP), perhaps
putting it into an ebXML registry.  Each new filer would substitute a few
parameters into fields of this CPP to form a customized CPA.  This CPA
would be used to configure the court and the filer's ebXML software for
the exchange of filings.  This is simple to automate.

One ebXML software vendor is working with a Law Document vendor and is
thinking of solutions along these lines.  They were nice enough to confirm
my understanding above. [5]

3. CDC XML and the Registry standard

Moving to the high-level information communication, the Court Data Control 
(CDC) document [10] specifies the parts needed by a particular court and the
restrictions on the element.  This document specifies such
things as the maximum length, ranges, parameters and code lists for data
elements in a filing.  

A concern is how a connecting organization would get the address of this
document.  An ebXML registry could be used--however, this is begging the
question.  The software would have now need the address of the ebXML registry
that it is to contact to get the CDC XML.

The Registry can also be used to contain the CPA's for courts and Electronic
Filing Service Providers.  The, the registry would provide a way that these
entities could "find each other" to "do business."

4. Defining the Payload and the Universal Business Language

The Oasis Universal Business Language (UBL) Technical Committee is developing a
library of XML components that can be used in many documents.  They have
developed the components necessary for purchase orders and related documents.  
They started with the Commerce One xCBL 3.0 documents and definitions. [7][8] 
Most of these are not relevant to court Filing applications.  However, the 
electronic Court Filing group could use the elements defined for the United 
States Mailing Address definition, Payments, and Credit Card information.  
These would replace the "horizontal" elements that were defined for these 
purposes as part of the electronic Court Filing specification.

As mentioned earlier, the Court Data Control document discusses how the Court
Filing can be customized for the needs and rules of each courts.

At the Orlando interoperability seminar in late June 2002, Jon Bosak of the 
Universal Business Language committee said they are looking at this issue.  
Each user of UBL documents would have to specify which elements they need 
or don't need.  For example, every supplier and purchaser may not use every 
element that is defined in a UBL purchase order.

However, they are approaching the problem as a construction problem  -- which
components does each receiver expect included.  This is in contrast to the
approach envisioned in our Technical Committee -- what restrictions does each
entity impose upon a general document.  I have yet to find documents from
the UBL technical committee showing this approach.

I also note that the Universal Business Language  Technical Committee is
wrestling with the issue of handling code lists.  They address code lists
that are specified by an external agency such as the ISO language codes
or the NCIC codes for vehicle type.

The Electronic Court Filing TC is also facing this issue.   Code lists 
would be used in court filing for such features as:
   documentType, mailing address type (school, business, home, etc.),
   hair color, eye color, ethnicity, race, skin tone, blood type,
   vehicle make, etc.

See [6] for information on the options that the UBL TC is considering.

4. Summary and conclusions

Some of the Court Filing specifications concern low-level
details of how information is transferred from computer to computer.  ebXML
standards show how some of this work can be done by leveraging on these
standards.

The Universal Business Language Technical Committee is developing a technology
framework applicable to many areas of business; we should start looking at
their work on code lists and thier elements for addresses and payment 
information.

Bibliography and References

[1] Chappell, David A., et. al., Professional ebXML Foundations, Wrox Press,
Birmingham, UK, 2001

[2] OASIS ebXML Collaboration Protocol Profile and Agreement Technical
Committee,
Collaboration-Protocol Profile and Agreement Specification Version 2.0,
Version 2.0, June 5, 2002,
http://www.oasis-open.org/committees/ebxml-cppa/documents/ebcpp-2.0.pdf

[3] ebXML Messaging Services Technical Committee, Message Service
Specification, Version 2.0, April 1 2002,
http://www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v2_0.pdf

[4] OASIS LegalXML Member Section Electronic Court Filing
Technical Committee DRAFT Electronic Court Filing 1.1 Proposed Standard
http://www.oasis-open.org/committees/legalxml-courtfiling/documents/ecfs_proposed_std_1-1_071502.pdf

[5] Luger, Leanne, Zenaptix, Inc., Personal Communication, August 2002.

[6] Maler, Eve and Desre, Fabrice, Position Paper: Code Lists,
Proposal 09, 28 May 2002.
http://www.oasis-open.org/committees/ubl/ndrsc/pos/p-maler-codelists-09.pdf

[7] UBL Library Content SubCommitee Draft Distribution, March
12 2002, Available at http://oasis-open.org/committees/ubl/lcsc/

[8] UBL Marketing Subcommittee: UBL: The Next Step for
Global E-Commerce, April 2 2002,
http://oasis-open.org/committees/ubl/msc/200204/ubl.pdf

[9] Walsh, Aaron E. (ed),ebXML, The Technical Specifications, Prentice Hall PTR,
New Jersey, 2001.

[10] Yuan, Mark and Spohn, Steve, EFM-CMS Interface Requirements,
Version 6, 2001