OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-courtfiling message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [legalxml-courtfiling] Contribution from OXCI project


Perfectly. Thanks.
 
Rolly Chambers

	-----Original Message----- 
	From: Cabral, James 
	Sent: Thu 3/13/2003 8:32 PM 
	To: Chambers, Rolly 
	Cc: 'legalxml-courtfiling@lists.oasis-open.org' 
	Subject: RE: [legalxml-courtfiling] Contribution from OXCI
project
	
	
	Rolly,
	 
	I apologize if my previous explanation for including the schema
in the OXCI Architecture was not clear.  Let me try this again.
	 
	The focus of the architecture document is a number of design
decisions.  We included the schema simply to show how those design
decisions (e.g., use of schemas, ebXML Messaging) would affect CF 1.1.
Ultimately, I believe the intention is that CF Blue will be based on the
JusticeXML 3.0 Core schemas and the Court Activity Object schemas.
Fortunately, GTRI is already incorporating support for namespaces and
data types in these schemas. However, I'm not sure if they are
addressing the wildcard issue.  Perhaps this is something that the Court
Filing representatives to the GTRI process should address.
	 
	Does this clarify?
	 
	  Jim Cabral

		-----Original Message-----
		From: Rolly Chambers [mailto:rlchambers@smithcurrie.com]
Sent: Thursday, March 13, 2003 4:45 PM
		To: legalxml-courtfiling@lists.oasis-open.org
		Subject: Re: [legalxml-courtfiling] Contribution from
OXCI project
		
		
		Jim and others -
		 
		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."
		 
		Rolly Chambers 

			----- Original Message ----- 
			From: Cabral, James <mailto:jcabral@mtgmc.com>  
			To: Chambers, Rolly
<mailto:rlchambers@smithcurrie.com>  
			Cc: legalxml-courtfiling@lists.oasis-open.org
<mailto:legalxml-courtfiling@lists.oasis-open.org>  
			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> 


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]