Thanks for the informative responses. It is good to get a clearer
picture of what the OXCI Architecture includes and what it does not.
From my perspective, it would be great if the baseline OXCI Architecture
was extended to include service of filings (and documents that are required to
be served but not filed) on other parties. Roger Winters made the
point (better than I did) that including such functionality is important to
gaining law firm participation in e-filing. If moving the
baseline isn't practical, then it would be prudent to describe how the
baseline Architecture can be extended to provide "service of filings"
functionality.
As for the CF XML schema, I'm now a little unclear about its intended
purpose. If it is a "demonstrator" not intended for use, I agree that it is a
good illustration of how the CF 1.1 DTD might be translated into an XML
schema. If it is intended for use, however, I think the "XML namespace" and
the "ANY content - XML schema wildcard" issues ought to be cleared up. Use
of enumerated element values and data typing certainly can wait until the later
CF schema is created, although implementing those features need not lead to any
incompatibility between the proposed XML schema and the CF 1.1
DTD.
At any rate, what you have put together in the paper is excellent. I join
in John Messing's "well done."
----- Original Message -----
Sent: Thursday, March 13, 2003 5:28
PM
Subject: RE: [legalxml-courtfiling]
Contribution from OXCI project
Rolly,
I appreciate your taking the time to carefully review the OXCI
EFM
Architecture document. You raise some very
good points and I my responses
align with the
consensus below. But to respond to the points directly:
1. Service of documents on other parties
In my understanding, the OXCI Architecture is intended to
provide a baseline
EFM for court filing that does not
necessarily include service of filings on
other
parties. It is well expected that vendors will provide other EFM
implementations with more functionality such as srevice of
filings on other
parties. These products may or
may not be based on the OXCI EFM. That is,
the
OXCI Architecture does not specifically support this service but, as
Dallas Powell clearly points out, the Architecture could be
extended fairly
easily to include it.
2. Proposed Court Filing XML Schema
The purpose of including the schema was simply to demonstrate
how the Court
Filing 1.1 DTD might translate to a
compatible schema and to demonstrate how
certain
elements would change based on the design decisions. Tom Clarke
and
John Greacen may have been premature in publicly
calling this "Light Blue".
In my opinion, your
suggestions for changes to the schema are right on the
money and should be incorporated in the CF Blue schema.
Jim Cabral
-----Original Message-----
From:
jmessing [mailto:jmessing@law-on-line.com]
Sent: Thursday, March 13, 2003 12:08 PM
To: legalxml-courtfiling@lists.oasis-open.org; Dallas
Powell
Subject: Re: [legalxml-courtfiling]
Contribution from OXCI project
What is described as the role of the Bar Association is not
the practice in
any jurisdiction I am aware of. The
attorneys in the case are responsible
for providing to
all the other attorneys in the case the address by which
they are to be served by mail.
---------- Original Message
----------------------------------
From: Dallas Powell
<dpowell@tybera.com>
Date: Thu, 13 Mar
2003 13:05:50 -0700
>I sent this response directly to Rolly, but perhaps others
may be
>interested in the message.
>
>> Rolly,
>>
>> The OXCI document refers to
the document "Architecture Models,
>> Business
decisions, and Interoperability Issues"
>> http://www.tybera.com/E-Filing%20Architecture%20Models%20and%20Issues
>> .htm
>.
>> OXCI indicates that who ever implements OXCI needs to support
all
>> models defined in this document.
That being the case, if you look at
>> the
last
>two
>>
diagrams, (or the one I have included here) what those diagrams are
>> saying is that an attorney can install the
exact same software the
>> court
>installs,
>> that is, an
EFSP and an EFM. Therefor if two attorneys install this
>> software, they can then file, or serve documents onto each
other. In
>> addition, an attorney's
client can use the EFSP provided by the
>>
attorney
>so
>> that
the clients can file documents to the attorney. Then, if
>corporations
>> install the
software, they can begin to exchange, file, serve...
>> documents onto each other. In reality, this model begins
to create a
>> spiders web of installations with
a complex method of managing how
>> multiple EFM
installations control which EFSP installations can
>> submit information to each other, or even more specifically,
what
>> types of filings each
>authorized
>> EFSP can submit. to the
various EFMs.. It suggests that when a Judge
>> creates a ruling, they can initiate a filing back to the
participating
>> attorneys. (Two way
automation) Although the diagram represents this
>> behavior, these concepts were not within the initial scope of
>> original document. The original
document was intended to demonstrate
>> to the
TC
>that
>> there are
multiple designs by which a court could interact with
>> attorneys.
>>
>> The model that is shown in the attached diagram is the
architecture
>> that
>is
>> being implemented in Utah Court
Filing 1.1 implementation. There are
>>
attorneys and other state agencies preparing to install both an EFSP
>> and
>EFM
>> at their locations. However, it is my opinion
that in order to
>> sustain a system that
officially allows attorneys to serve each other
>> it will become the responsibility of the Bar Association to
provide a
>> registry for the attorneys to
indicate which attorneys support this
>> method
of service. In the same fashion, it is the responsibility of
>> the Bar Association to
>publish
>> the official mailing
address to serve documents on another attorney,
>> or in the case of Corporations, it will be the responsibility
of the
>> Department
>of
>> Commerce to maintain a registry
of companies who support the
>> interface
to
>be
>> served
electronically since the DOC licenses and maintains a registry
>> of companies and official addresses.
>>
>> I really don't
believe OXCI intended to extend their design this far,
>> but that is the intent of the diagram.
>>
>> Dallas
>
>----- Original Message -----
>From: "jmessing" <jmessing@law-on-line.com>
>To: "Court Filing List"
<legalxml-courtfiling@lists.oasis-open.org>
>Sent: Thursday, March 13, 2003 12:17 PM
>Subject: RE: [legalxml-courtfiling] Contribution from OXCI
project
>
>
>> I agree with Roger and Rolly that electronic service
by the courts or
>EFSP's is a probable incentive to
lawyers, depending of course on how
>it is handled.
I understand "service" in this context to exclude the
>initial step of filing of a complaint and se
>> rvice of a summons, which presents different issues.
>>
>> Service of paper
pleadings by mail is a thankless chore to most
>> lawyers.
>Eliminating it may
immediately cut down the overhead of printing and
>mailing such documents by law firms, if no additional fees or very
>nominal ones are charged for the service.
>>
>> In my days of
running the Pima County Justice Court small claims
>> project,
>I was impressed with the
return receipt service of process that the
>court
effectuated by postal mail for the nominal sum of $3.50 per case.
>The litigants were not lawyers, admitte
>> dly, but the convenience and efficiency of the
process was greatly
>appreciated by the public and
went far in helping the popularity of the
>court,
with or without electronic filing.
>>
>> Service effectuated directly between lawyers can
also generate a most
>frustrating class of dispute
that service through the court or an EFSP
>may
eliminate. Without telling tales out of school, consider the
>anectode of the lawyer who is often suspected o
>> f using the stamp of a postage meter in a mysterious way to
make it
>> appear
>that a document was sent by US mail earlier than it really was. Or
its
>cousin that relates the practices of a crafty
lawyer who is known in a
>community for turning off
the fax at
>> times to stymie the use of
faxed service of documents by an
>> opponent.
I
>imagine the use of junk email filters could be
the next generation of
>devices lawyers could
creatively put to use in such situations. Taking
>service out of the hands of the lawyers
>> and putting it with the courts or EFSP's could itself be
a big
>> selling
>point to lawyers who have grown weary of such practices.
>>
>> I also appreciate
the fine efforts of Mr. Cabral and his group in
>effectuating a very difficult task. I think the report was
extremely
>professional and well-done.
>>
>> A common thread
that I extract from the two previous comments is
>> whether
>we are in a position yet
to give a complete and meaningful response
>about
OXCI. As Rolly points out, we do not have the schema, and the
>report had to fashion a crude prototype usin
>> g XML Spy for its working assumptions. Also, the CMS-API
workgroup
>> has not
>completed a piece that OXCI requires and assumes will be in place,
>which is the CMS-API. I do not blame anyone for
this occurence. Some of
>the problems are hopefully
being worked
>> out. In the absence
of the API, I can only guess if the overall
>> system
>as envisioned can be made
to work as intended.
>>
>> I am also unclear if the methods already used by some vendors
will be
>facilitated or hindered by the envisioned
architecture. I think their
>frank input is
indispensible, and I would prefer to hear the results of
>Dallas Powell's interoperability subcommi
>> ttee on the differences in filing techniques between various
vendors
>before finalizing any evaluation of the
OXCI study. It seems that
>BearingPoint.com has
certain methods that are being used in Texas;
>Tybera has others that are used in Utah, still othe
>> rs may be used by Mo Abdulaziz' court in Arizona;
and there may be
>> others
>from LexisNexis in Colorado. Perhaps the cataloging of the
similarities
>and differences will better arm us
with specifics as a basis for a
>meaningful
response to the OXCI group.
>>
>>
>>
>>
>> -----Original
Message-----
>> From: Winters, Roger [mailto:Roger.Winters@METROKC.GOV]
>> Sent: Thursday, March 13, 2003 9:42 AM
>> To: 'Tom.Clarke@courts.wa.gov';
'rlchambers@smithcurrie.com';
>'legalxml-courtfiling@lists.oasis-open.org'
>> Subject: RE: [legalxml-courtfiling] Contribution from OXCI
project
>>
>>
>> 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
servic
>> e. 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#ElectronicFili
>ngPro
>cesses.
>>
>>
>>
>> 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 importa
>> nt 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 appro
>> ach 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 cr
>> eating 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 con
>> tent, 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 X
>> ML 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 requi
>> red 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
t
>> he 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 als
>> o 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>
>
>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>