RE: [legalxml-courtfiling] Contribution from OXCI project

[jmessing <jmessing@law-on-line.com>]

I think Allen brings up a very good point. I suppose at one level since the service of pleadings or other documents is optional under this  OXCI proposal, a court could just choose not to provide it. 

At another level, if objects are updating the CMS' automatically at both ends of the pipeline as Dallas envisions, then the issues become: first, who is responsible for monitoring the automated processes to make sure all goes as expected and for issuing the certificates of service as proof the data was properly sent and received? Secondly,what signature technology is used as proof of authority and authenticity of these events?

Assuming a business decision were reached by a court to be the responsible entity for service results, and a clerk was selected to sign certificates of service on its behalf, would it be correct to conclude that a court could not accomplish this feat technically because there is no security through signature technology assumed by, allowed for, or enabled on the court side of this proposed version of OXCI?

Are there any restrictions in terms of architecture or parameters likely to result from this proposed version of OXCI imposed upon a signature technology of an EFSP, court, or law firm signer?

---------- Original Message ----------------------------------
From: Allen Jensen <ajensen@occourts.org>
Date:  Thu, 13 Mar 2003 16:14:31 -0800

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










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