legalxml-courtfiling — archive

[Robert DeFilippis]

 MHonArc v2.5.0b2 -->
















legalxml-courtfiling message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: RE: [legalxml-courtfiling] Please review 'Proposed Service Models for ECF3'




From: "Robert DeFilippis" <RTD@onelegal.com>
To: "Dallas Powell" <dpowell@tybera.com>,"Bergeron, Donald L. \(LNG-DAY\)" <Donald.Bergeron@lexisnexis.com>,"Cabral, James E." <JCabral@mtgmc.com>,"Electronic Court Filing Technical Committeee" <legalxml-courtfiling@lists.oasis-open.org>
Date: Wed, 29 Jun 2005 12:28:47 -0700






Title: Please review 'Proposed Service Models for ECF3'



Dallas:
 
In my mind, you raise a valid point about our time 
constraints and the possibility of deferring eService from CF2.0.  Jim 
Cabral mentions, in his post last night, the considerable response on this 
subject and that tells me more time is needed (more than we have) to 
properly vet the various options.  We can not afford to miss the 
pending presentation deadline because of this issue.
 
-Robert




From: Dallas Powell [mailto:dpowell@tybera.com]
Sent: Wednesday, June 29, 2005 11:01 AM
To: Bergeron, 
Donald L. (LNG-DAY); 'Cabral, James E.'; Electronic Court Filing Technical 
Committeee
Subject: Re: [legalxml-courtfiling] Please review 'Proposed 
Service Models for ECF3'



If we are going to hedge our bet because of time 
constraints then we should eliminate eService from court filing 2.0 rather than 
hope to get even one of the models right.  Tybera has already worked 
on model B because of customer demand, and I think that is valid business 
reason.  
 
An issue that came to our attention last night as 
we were continuing to review the eService concerns is regarding relationships in 
the database.  Court filing 2.0 includes the ability for the submitter to 
be different than the legal representative that signs the document.  
That means the central database must have a relationship between the 
submitter, the legal rep, and the party represented.  I am 
concerned that we have not worked through those issues yet.  
 
Also, the concept of a ServiceID really does 
not function properly because an ID to me refers to a number, and that 
number may be an entry in a table that contains URL info, communication info, 
and so forth.  It is not clear to me if the intent of the serviceProfile 
info is designed to make up the amount of information missing from an 
ID.
 
Anyway, the idea that this will be easy 
and to move forward with one model does not seem correct to 
me.
 
Dallas