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: "Bergeron, Donald L. (LNG-DAY)" <>
To: "'Dallas Powell'" <>, "'Cabral, James E.'" <>, Electronic Court Filing Technical Committeee <>
Date: Wed, 29 Jun 2005 14:29:06 -0400
Title: Please review 'Proposed Service Models for ECF3'
I understand and agree with 's point. He's key point
is that if the court is not going to be willing to be the registration point the
community should have a readily available alternative. It really is a
community and priority/political issue. I can personally live with either
solution.
Regretfully, I will not be the do attend
tomorrow's conference call as I will be moving my stepdaughter. This wishes
and bring this to closure.
Regards,
Don
Donald L. Bergeron
Systems Designer
LexisNexis
O 937-865-1276
H 937-748-2775
M 937-672-7781
From: Dallas Powell
[mailto:]
Sent: Wednesday, June 29, 2005
2:01 PM
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.
