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" <>
To: "Dallas Powell" <>,"Bergeron, Donald L. \(LNG-DAY\)" <>,"Cabral, James E." <>,"Electronic Court Filing Technical Committeee" <>
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:]
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
