Re: [legalxml-courtfiling] Contribution from OXCI project

[Dallas Powell <dpowell@tybera.com>]

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#ElectronicFilingPro
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>

Multiple installations .ppt

Multiple installations .jpg