[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: eService process descriptions
|
Shane,
In answer to your P.S., yes, we now have a subcommittee
list. I've included the list in this reply. I am hoping others will
do the same.
In response to your points, like you, I have been
concerned about a centralized model for e-service and the issues with
registration in that model. I also agree that registering as a party to a
case that can receive filings electronically (is that secondary
service?) is different from registering to receive service for any case
(which isn't primary or secondary service in my
understanding).
I have CCed John Greacen as well because he seemed to be
the strongest advocate for that model at the face-to-face. I understand
John is out of the country but I'm hoping he at least can respond to
emails.
Jim Cabral From: Shane.Durham@lexisnexis.com [mailto:Shane.Durham@lexisnexis.com] Sent: Wednesday, January 05, 2005 1:29 PM To: dpowell@tybera.com; Cabral, James E.; scott@justiceintegration.com; Tom.Clarke@courts.wa.gov Subject: eService process descriptions Dallas, et al,
(Happy new
year)
I agree that there may be a
different set of functional features between a vendor-to-vendor approach, vs. a
vendor-to-server approach. (Note: this conversation parallels the usual
peer-to-peer vs client-server discussions that occur so frequently in our
work.)
Let's discuss - I'll try to get the
ball rolling...
The biggest functional
distinction that comes to mind:
In the peer-to-peer approach that
I have been pondering, I have successfully avoided the discussion of
how attorneys would become registered to receive eservice (aka 'eservice
registration' or, for this conversation, let's call it
'registration'.)
In a peer-to-peer approach, the
attorney's 'eservice component' is aware of its own attorneys' eservice
preferences. Conveniently, the 'registration' process becomes a
private function between an eservice component and its users. Each
'eservice component', is free to manage their users service profiles and
preferences however they see fit, and to facilitate maintenance by whatever
means is appropriate.
On the other hand...
In a client-server process, there
exists a SINGLE centralized system, responsible for tracking everyone's
eservice preferences. Consequently, it must
also define the SINGLE process by which any member of the filing
community can create, update, or remove their eservice preferences (and,
also, make sure users can NOT update others' service
preferences). Such a 'registration' process would not
necessarily have to be electronic (we *could* continue to side-step the
issue)... but, more than likely, it *would* be an electronic process, and, then,
fall in our laps to define.
The scary part of such a
registration process, is that there isn't a good paper-world model for us to
follow. To my knowledge, there is no paper-world system, where the
community of users agree to maintain a SINGLE eservice list for ALL members of
the community. And so, there are no existing paper-world rules that
dictate HOW and WHEN a centralized eservice list would be updated.
I think that many of us believe
that the courts currently *do* manage eservice lists (eg a case's party list) -
but, every time I dig a little deeper, it turns out not to be true.
Clerks maintain case records - not eservice lists. There is a
difference. An attorney's eservice list is often a bit broader
and often a bit more precise than the court's case
records.
And, it is at that point, where I feel
we run into something that is outside the scope of our requirements group.
If there is no paper-world authority to maintain a centralized eservice list,
then I think we can't invent one in the electronic world.
It is certainly reasonable for this
group to define electronic equivalents of existing (paper-world)
processes. It is quite a different (and much more difficult) task for us
to invent processes (ie 'central authorities') that don't presently
exist. At the least, it's a red flag, eh?
- Shane 'peer-to-peer'
Durham
PS: Is there a new workgroup list in
which this discussion should be documented?
-----
Original Message -----
From: Clarke,
Tom
Sent: Wednesday, January 05, 2005 12:27 PM
Subject: RE: [legalxml-courtfiling] eService process
descriptions Dallas, two comments:
I think your interpretation accords well with the component approach we are trying to take. I don’t think you got Shane on your address list, so he didn’t see your email.
-----Original
Message-----
If from your comments your suggestion is to avoid the distinction between court controlled or vender controlled, I agree. However, I think that the intent of the distinction is the different feature set needed when multiple entities are sanctioned as service providers vs. one entity. Whether a single entity sactioned is the court, the bar, or a vendor, and what role must be played when the different situations take place. We need to define the feature sets for both and distinguish between them.
Dallas
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]