Re: [legalxml-courtfiling] Contribution from OXCI project

[Dallas Powell <dpowell@tybera.com>]

Interesting.  It demonstrates how different each state rules are governed.
In Utah, the Bar Association told us, Tybera, they are the authority of
addresses for Attorneys.  http://www.utahbar.org/html/find_a_lawyer.html
They have stated that if the address of the attorney changes and they do not
notify the Bar within a certain time frame, they could suspend the attorneys
license.  It is also the case with the DOC and Corporations.

Dallas

----- Original Message -----
From: "jmessing" <jmessing@law-on-line.com>
To: <legalxml-courtfiling@lists.oasis-open.org>; "Dallas Powell"
<dpowell@tybera.com>
Sent: Thursday, March 13, 2003 1:08 PM
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#ElectronicFilingPr
o
> >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>


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