RE: [legalxml-courtfiling] Contribution from OXCI project

[Allen Jensen <ajensen@occourts.org>]

A concern some courts could have would be the liability or responsbility
to the court for handling the 'Serving' item.  What liability would the
court face if there was any failure in that process, be it a mistyped or
not updated email address, system downtime, or any other failure? 
Should the court take that responsibility?

Kind of along the lines of why the Bar expressed concern about using
EFiling for the mere sake of liability if something prevented the filing
from making it through I guess.



Allen Jensen
Orange County Superior Court
Internet Development / EFiling
949.472.6946  Tel.
714.647.4805  Fax



>>> "Winters, Roger" <Roger.Winters@METROKC.GOV> 03/13/03 08:41AM >>>
At Tom's suggestion, I'll speak up about how the "Standards for
Electronic
Filing Processes" treats service of filings. In the section on "Court
Rules," "Standard 1.2A Service of Filings on Opposing Parties" (pages
34-35
of the February 26, 2003 version) identifies electronic service as an
"important incentive for lawyers' use of electronic filing." Further,
it
says "the efficiency of the legal process will be enhanced by having
service
performed by the electronic filing process." 

 

The corresponding "Functional Standard 3.14: Service and Notice," (page
91)
in Subfunction 3.14.1 notes that providing this service is optional,
not
mandatory: "It is optional for each electronic filing system to provide
for
electronic notice and service. When a court opts for this
functionality, the
system must provide a proof of service record and a record of who is
served
electronically and who must still be served traditionally."

 

The document from which this information is taken can be found at
http://www.ncsconline.org/D_Tech/Standards/Standards.htm#ElectronicFilingPro

cesses
<http://www.ncsconline.org/D_Tech/Standards/Standards.htm#ElectronicFilingPr

ocesses> . 

 

Though not directly involved with the group who have been developing
OXCI, I
will say I didn't expect OXCI to embody many, if any, of the optional
functions and processes, including the electronic service function.
This is
not to say it isn't as important as Rolly indicates. In fact, his
calling it
out helps me understand even more clearly how service and related
functions
(e.g., document exchanges not directly related to a filing) are
probably
going to be needed if we are to get substantial law firm participation
in
our e-filing systems.

 

Regards,

 

Roger

 

Roger Winters

Electronic Court Records Manager

King County
Department of Judicial Administration

516 Third Avenue, E-609 MS: KCC-JA-0609

Seattle, Washington 98104

V: (206) 296-7838 F: (206) 296-0906

roger.winters@metrokc.gov 

 

-----Original Message-----
From: Tom.Clarke@courts.wa.gov [mailto:Tom.Clarke@courts.wa.gov] 
Sent: Thursday, March 13, 2003 8:22 AM
To: rlchambers@smithcurrie.com;
legalxml-courtfiling@lists.oasis-open.org 
Subject: RE: [legalxml-courtfiling] Contribution from OXCI project

 

Rolly,

 

I don't want to speak for MTG, but I do know something about the intent
of
what they submitted.

 

One of the problems with the OXCI project is that they don't want to
set
standards, they also don't want to do things that are obviously
undesirable
from an architectural viewpoint, and they don't want to be any more
incompatible with projects building on CF 1.1 than necessary.  MTG
attempted
to compromise by absolutely minimizing the changes necessary to get
from
Court Filing 1.1 to a schema that is consistent with a web services
approach
to messaging.  We jokingly called this "Light Blue" because we knew the
TC
would want to go further with the real Blue.  Specifically, you would
probably want to take better advantage of schema features, as you
propose
below, at the expense of backward compatibility with CF 1.1.

 

I don't think anyone involved with OXCI envisions implementing service
outside of the core architecture of Legal XML transactions.  If that is
not
clear from the document, then we will need to clarify that for
potential
OXCI vendors.  I believe an approach implementing service and other
notice
types through the core component set over the Internet, as opposed to
separate noticing via email, is recommended by the COSCA/NACM national
standard for e-filing.  If I'm wrong about this, others involved in
creating
that standard should speak up.

 

Jim Cabral from MTG is the actual author of the document, so he can
better
respond to your specific suggestions.

 

-----Original Message-----
From: Chambers, Rolly [mailto:rlchambers@smithcurrie.com] 
Sent: Wednesday, March 12, 2003 7:55 PM
To: Electronic Court Filing Technical Committeee
Subject: RE: [legalxml-courtfiling] Contribution from OXCI project

 

I commend MTG and its contribution to the TC of the OXCI Electronic
Filing
Manager Architecture. The design decisions have been thoughtfully
considered
and sound choices have been made.

 

I have one question/comment regarding the architectural piece and a
handful
of comments/thoughts concerning the proposed Court Filing XML schema.

 

The Architecture focuses on filings with a court appropriately enough,
but
it was not clear how or whether the architecture also supports the
service
of filings by a filer on other parties or their attorneys. Procedural
rules
require me, as a lawyer, to send (i.e. serve) other parties in a case
with
copy of pleadings, motions, or other filings that I submit to a court.
Does
the OXCI architecture support this service function or does it assume
that
lawyers will submit filings to a court electronically via applications
implementing the proposed architecture but then serve copies of the
filings
on each other by some other means such as regular mail, hand-delivery,
or
email?

 

A related question concerns whether the OXCI architecture supports the
service on other parties or their attorneys of documents that are not
filed
with a court such as discovery (interrogatories, requests for
production of
documents, deposition notices, offers of judgment, etc.).

 

The Court Filing XML schema apparently was generated by the DTD to XML
schema feature of XML Spy. Like similar DTD to XML schema applications,
the
result is a fairly decent XML schema. However, the resulting XML schema
can
be substantially improved and made more useful by modest editing to
add
features available in XML schemas but not available in DTDs. Providing
for
the following in the proposed XML schema would be useful:

 

XML namespaces - the proposed XML schema has no default or
targetNamespace.
An XML schema "best practice" is to declare the targetNamespace as the
default namespace. This approach eliminates problems with element name
collisions and other problems when one schema, such as the Court Filing
XML
schema, is used with another, such as the SOAP schema. Creating an XML
namespace for the proposed Court Filing XML schema would improve its
utility
significantly.

 

ANY content elements - the DTD to XML schema converter changed elements
in
the DTD having ANY content (e.g. administrativeLaw, civil,
domesticRelations, etc.), which can contain any of the other elements
declared in the DTD, to elements having mixed content, which can
contain
text and specifically declared elements. The mixed content elements in
the
proposed XML schema, however, contain no declared elements. Thus,
filings
containing an element within <civil/> will be valid against the Court
Filing
DTD, but not against the proposed XML schema. The wildcard component of
XML
schema is capable of providing substantially the same function as ANY
content in a DTD. Changing the "empty" mixed content elements in the
proposed Court Filing XML schema to use XML schema wildcards would make
the
schema more equivalent to the DTD.

 

Enumerated element values - XML schema allow the declaration of
enumerated
values for elements in addition to attributes. Many of the elements
(hairColor, eyeColor, race, etc.)  in the Court Filing 1.1 DTD have
required
data values. Including such required data values as enumerated element
values in the proposed schema would prevent problems that might occur
if an
element in a filing fails to contain the data value required by the
Court
Filing 1.1 spec.

 

Datatyping - one of the major advantages of XML schema over DTDs is
datatyping. There are built-in data types available in XML schema for
date,
time, integer, decimal, and others. It also is possible to declare
datatypes
for data items such as zip codes or telephone numbers. The proposed
Court
Filing XML schema uses only the string data type, but might be made
more
useful if other XML data types were used where appropriate.

 

I again commend MTG's contribution. Thanks for soliciting and
considering
these suggestions.

 

Rolly Chambers 

-----Original Message----- 
From: John Greacen 
Sent: Mon 3/10/2003 6:16 PM 
To: Electronic Court Filing Technical Committeee 
Cc: 
Subject: [legalxml-courtfiling] Contribution from OXCI project

I enclose a zipped file containing a report from MTG for OXCI including
a
series of architectural recommendations for the OXCI product and draft
schemas for court filing and query and response.  The court filing
schema
incorporates ebXML messaging and the elements from the current version
of
the JXDDS.  Those are two of the objectives we have set for ourselves
for
Electronic Court Filing "Blue."  OXCI is contributing these work
products to
this Technical Committee to use as we see fit.  OXCI would also
appreciate
feedback on the architectural piece and on the schemas.

 

John M. Greacen

Greacen Associates, LLC

HCR 78, Box 23

Regina, New Mexico 87046

505-289-2164

505-780-1450 (cell)

 


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>