openefm-development — Developer Discussion

[Openefm-development] File Release & Web Site Update

[Jim B. <be...@co...>]

I just wanted to send out a quick note to let everyone know that I 
replaced the 1.0 file releases.  When I had uploaded the 1.3 releases 
onto sourceforge I unintentionally overwrote the 1.0 version.  This has 
been fixed and the old 1.0 versions are back again.  The web page also 
received a purely cosmetic facelift to accommodate for our solidified 
product naming convention.

Thanks,

Jim Beard
counterclaim.com, Inc
http://www.counterclaim.com
http://openefm.sourceforge.net
(800) 264-8145

Re: [Openefm-development] Authentication and Attorney Registration

[Jeremiah J. <jer...@go...>]

I've got to lay of the crack rock....I was looking straight at it (quite
literally) the whole time...doh!

-jj-


On Tue, 2005-03-08 at 17:24 -0800, Jim Beard wrote:
> On Mar 8, 2005, at 2:55 PM, Jeremiah Jahn wrote:
>=20
> > On Tue, 2005-03-08 at 13:14 -0800, Jim Beard wrote:
> >> On Mar 8, 2005, at 11:43 AM, Jeremiah Jahn wrote:
> >>
> >>> On Tue, 2005-03-08 at 12:08 -0600, Jeremiah Jahn wrote:
> >>>> or to phrase it another way, Who do you idenifiy Who, not where, the
> >>>> filing came from?
> >>>
> >>> cause I can type....that should read HOW do you identify who not=20
> >>> where
> >>> the filing came from?
> >>
> >> Our current model requires the EFSP to identify itself with a name and
> >> password for authentication.  The identity of the filing party is
> >> contained with in the XML filing.  We parse the party information from
> >> the filing.  We leave the authentication of the filing party up to the
> >> EFSP and the court.  It has been our belief that this is similar to=20
> >> how
> >> filings work in real life.  If I want to fake my identity, I can walk
> >> into a court and claim to be someone I am not.  Ultimately it would
> >> seem to be the courts responsibility to verify that this is true.
> > looking at the examples contained in CVS, none of them actually specify
> > who the filer is. Am I missing something?
>=20
> The court filing 1.1 sample has a "filed by party" identified in the=20
> XML.  I believe the 2GEFS version does as well.  I would not be=20
> surprised if this is not as clear in the OXCI samples as that=20
> specification was not as advanced or not tested as well.
>=20
> Jim Beard
> counterclaim.com, Inc
> http://www.counterclaim.com
> http://openefm.sourceforge.net
> (800) 264-8145
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Openefm-development mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openefm-development
If you cannot convince them, confuse them. -- Harry S Truman

[Openefm-development] Authentication and Attorney Registration

[Jim B. <be...@co...>]

On Mar 8, 2005, at 2:55 PM, Jeremiah Jahn wrote:

> On Tue, 2005-03-08 at 13:14 -0800, Jim Beard wrote:
>> On Mar 8, 2005, at 11:43 AM, Jeremiah Jahn wrote:
>>
>>> On Tue, 2005-03-08 at 12:08 -0600, Jeremiah Jahn wrote:
>>>> or to phrase it another way, Who do you idenifiy Who, not where, the
>>>> filing came from?
>>>
>>> cause I can type....that should read HOW do you identify who not 
>>> where
>>> the filing came from?
>>
>> Our current model requires the EFSP to identify itself with a name and
>> password for authentication.  The identity of the filing party is
>> contained with in the XML filing.  We parse the party information from
>> the filing.  We leave the authentication of the filing party up to the
>> EFSP and the court.  It has been our belief that this is similar to 
>> how
>> filings work in real life.  If I want to fake my identity, I can walk
>> into a court and claim to be someone I am not.  Ultimately it would
>> seem to be the courts responsibility to verify that this is true.
> looking at the examples contained in CVS, none of them actually specify
> who the filer is. Am I missing something?

The court filing 1.1 sample has a "filed by party" identified in the 
XML.  I believe the 2GEFS version does as well.  I would not be 
surprised if this is not as clear in the OXCI samples as that 
specification was not as advanced or not tested as well.

Jim Beard
counterclaim.com, Inc
http://www.counterclaim.com
http://openefm.sourceforge.net
(800) 264-8145

Re: [Openefm-development] Authentication and Attorney Registration

[Jim B. <be...@co...>]

On Mar 8, 2005, at 11:43 AM, Jeremiah Jahn wrote:

> On Tue, 2005-03-08 at 12:08 -0600, Jeremiah Jahn wrote:
>> or to phrase it another way, Who do you idenifiy Who, not where, the
>> filing came from?
>
> cause I can type....that should read HOW do you identify who not where
> the filing came from?

Our current model requires the EFSP to identify itself with a name and 
password for authentication.  The identity of the filing party is 
contained with in the XML filing.  We parse the party information from 
the filing.  We leave the authentication of the filing party up to the 
EFSP and the court.  It has been our belief that this is similar to how 
filings work in real life.  If I want to fake my identity, I can walk 
into a court and claim to be someone I am not.  Ultimately it would 
seem to be the courts responsibility to verify that this is true.

In the implementation we built for the Supreme Court of Guam, they 
choose to control account creation at the EFSP.  They required parties 
who wanted to file to fill out a form at the court.  Then the court 
clerk created their account on the EFSP.  This was their way to control 
and authenticate filers.

Jim Beard
counterclaim.com, Inc
http://www.counterclaim.com
http://openefm.sourceforge.net
(800) 264-8145

Re: [Openefm-development] Authentication and Attorney Registration

[Jeremiah J. <jer...@go...>]

On Tue, 2005-03-08 at 12:08 -0600, Jeremiah Jahn wrote:
> or to phrase it another way, Who do you idenifiy Who, not where, the
> filing came from?

cause I can type....that should read HOW do you identify who not where
the filing came from?

>=20
> On Tue, 2005-03-08 at 09:49 -0800, Jason Van Cleve wrote:
> > Quoth Jeremiah Jahn, on Tue, 08 Mar 2005 11:10:59 -0600:
> >=20
> > > What's the standard authentication scheme for the EFP to use with the
> > > EFM?=20
> >=20
> > Here again let it be said, there is really no industry standard for thi=
s
> > stuff.  We have been using HTTP BASIC, for simplicity.
> >=20
> > > Does the court use the EFM to setup users and then the user take that
> > > id/password to the EFP and register it? Then does it use that ip/pass
> >=20
> > Yes, if I follow you.
> >=20
> > > pair to insure that a filer is who they say they are? It seems that
> >=20
> > Not the IP, just the login.  I could code in an IP check easy enough,
> > though, for cases where that is static.
> >=20
> > > you need more than just an ID to associate who filed what. If I find
> >=20
> > The EFM user is needed for the EFP to connect to the EFM.  The EFP has
> > users of its own.  To which are you referring?  Currently our EFM takes
> > no interest in EFP users.  If there is a billing operation to perform,
> > we take the necessary data from the legal XML, but we do not relate
> > those data to any "user" entity.
> >=20
> > > out that atty bob's id is 12 and I register with the EFP to use id 12
> > > when dealing with a court's EFM all sorts of bad things could happen.
> > > When I look at the examples and you code, I see no references to the
> > > actual filer, nor any security to insure they are who they say they
> > > are...I do see id/pass for the EFP to connect to the EFM, but that
> > > doesn't seem like enough. What is the general procedure for this stuf=
f
> > > to work? This also brings up the question of how do PRO SE filers get
> > > identified/approved with the court?=20
> >=20
> > I'm glad you're looking closely.  Our EFM is fundamentally agnostic.=20
> > Accordingly, it doesn't care much for the content of filings, just thei=
r
> > form.  The paradigm, I would say, is that if it's good enough for the
> > clerk reviewing it, it's good enough for the EFM.  So to answer your
> > question, our EFM doesn't authenticate users of the EFP, only the EFP
> > itself.  To OpenEFM, the EFP is the user.
> >=20
> > --Jason
> >=20
> > --
> > If you are going through hell, keep going. -- Sir Winston Churchill
> >=20
> >=20
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users=
.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> > _______________________________________________
> > Openefm-development mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openefm-development
> There is no such thing as fortune. Try again.
=46rom the Pro 350 Pocket Service Guide, p. 49, Step 5 of the instructions
on removing an I/O board from the card cage, comes a new experience in
sound: 5. Turn the handle to the right 90 degrees. The pin-spreading
sound is normal for this type of connector.

Re: [Openefm-development] Authentication and Attorney Registration

[Jeremiah J. <jer...@go...>]

or to phrase it another way, Who do you idenifiy Who, not where, the
filing came from?

On Tue, 2005-03-08 at 09:49 -0800, Jason Van Cleve wrote:
> Quoth Jeremiah Jahn, on Tue, 08 Mar 2005 11:10:59 -0600:
>=20
> > What's the standard authentication scheme for the EFP to use with the
> > EFM?=20
>=20
> Here again let it be said, there is really no industry standard for this
> stuff.  We have been using HTTP BASIC, for simplicity.
>=20
> > Does the court use the EFM to setup users and then the user take that
> > id/password to the EFP and register it? Then does it use that ip/pass
>=20
> Yes, if I follow you.
>=20
> > pair to insure that a filer is who they say they are? It seems that
>=20
> Not the IP, just the login.  I could code in an IP check easy enough,
> though, for cases where that is static.
>=20
> > you need more than just an ID to associate who filed what. If I find
>=20
> The EFM user is needed for the EFP to connect to the EFM.  The EFP has
> users of its own.  To which are you referring?  Currently our EFM takes
> no interest in EFP users.  If there is a billing operation to perform,
> we take the necessary data from the legal XML, but we do not relate
> those data to any "user" entity.
>=20
> > out that atty bob's id is 12 and I register with the EFP to use id 12
> > when dealing with a court's EFM all sorts of bad things could happen.
> > When I look at the examples and you code, I see no references to the
> > actual filer, nor any security to insure they are who they say they
> > are...I do see id/pass for the EFP to connect to the EFM, but that
> > doesn't seem like enough. What is the general procedure for this stuff
> > to work? This also brings up the question of how do PRO SE filers get
> > identified/approved with the court?=20
>=20
> I'm glad you're looking closely.  Our EFM is fundamentally agnostic.=20
> Accordingly, it doesn't care much for the content of filings, just their
> form.  The paradigm, I would say, is that if it's good enough for the
> clerk reviewing it, it's good enough for the EFM.  So to answer your
> question, our EFM doesn't authenticate users of the EFP, only the EFP
> itself.  To OpenEFM, the EFP is the user.
>=20
> --Jason
>=20
> --
> If you are going through hell, keep going. -- Sir Winston Churchill
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Openefm-development mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openefm-development
There is no such thing as fortune. Try again.

Re: [Openefm-development] Authentication and Attorney Registration

[Jeremiah J. <jer...@go...>]

Now I'm really confused...thanx..:)

How does the EFM know that a filing request comes from a legitimate
filer ie. some person that the court has okayed?=20

On Tue, 2005-03-08 at 09:49 -0800, Jason Van Cleve wrote:
> Quoth Jeremiah Jahn, on Tue, 08 Mar 2005 11:10:59 -0600:
>=20
> > What's the standard authentication scheme for the EFP to use with the
> > EFM?=20
>=20
> Here again let it be said, there is really no industry standard for this
> stuff.  We have been using HTTP BASIC, for simplicity.
>=20
> > Does the court use the EFM to setup users and then the user take that
> > id/password to the EFP and register it? Then does it use that ip/pass
>=20
> Yes, if I follow you.
>=20
> > pair to insure that a filer is who they say they are? It seems that
>=20
> Not the IP, just the login.  I could code in an IP check easy enough,
> though, for cases where that is static.
>=20
> > you need more than just an ID to associate who filed what. If I find
>=20
> The EFM user is needed for the EFP to connect to the EFM.  The EFP has
> users of its own.  To which are you referring?  Currently our EFM takes
> no interest in EFP users.  If there is a billing operation to perform,
> we take the necessary data from the legal XML, but we do not relate
> those data to any "user" entity.
>=20
> > out that atty bob's id is 12 and I register with the EFP to use id 12
> > when dealing with a court's EFM all sorts of bad things could happen.
> > When I look at the examples and you code, I see no references to the
> > actual filer, nor any security to insure they are who they say they
> > are...I do see id/pass for the EFP to connect to the EFM, but that
> > doesn't seem like enough. What is the general procedure for this stuff
> > to work? This also brings up the question of how do PRO SE filers get
> > identified/approved with the court?=20
>=20
> I'm glad you're looking closely.  Our EFM is fundamentally agnostic.=20
> Accordingly, it doesn't care much for the content of filings, just their
> form.  The paradigm, I would say, is that if it's good enough for the
> clerk reviewing it, it's good enough for the EFM.  So to answer your
> question, our EFM doesn't authenticate users of the EFP, only the EFP
> itself.  To OpenEFM, the EFP is the user.
>=20
> --Jason
>=20
> --
> If you are going through hell, keep going. -- Sir Winston Churchill
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Openefm-development mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openefm-development
A successful [software] tool is one that was used to do something
undreamed of by its author. -- S. C. Johnson

Re: [Openefm-development] Authentication and Attorney Registration

[Jason V. C. <ja...@va...>]

Quoth Jeremiah Jahn, on Tue, 08 Mar 2005 11:10:59 -0600:

> What's the standard authentication scheme for the EFP to use with the
> EFM? 

Here again let it be said, there is really no industry standard for this
stuff.  We have been using HTTP BASIC, for simplicity.

> Does the court use the EFM to setup users and then the user take that
> id/password to the EFP and register it? Then does it use that ip/pass

Yes, if I follow you.

> pair to insure that a filer is who they say they are? It seems that

Not the IP, just the login.  I could code in an IP check easy enough,
though, for cases where that is static.

> you need more than just an ID to associate who filed what. If I find

The EFM user is needed for the EFP to connect to the EFM.  The EFP has
users of its own.  To which are you referring?  Currently our EFM takes
no interest in EFP users.  If there is a billing operation to perform,
we take the necessary data from the legal XML, but we do not relate
those data to any "user" entity.

> out that atty bob's id is 12 and I register with the EFP to use id 12
> when dealing with a court's EFM all sorts of bad things could happen.
> When I look at the examples and you code, I see no references to the
> actual filer, nor any security to insure they are who they say they
> are...I do see id/pass for the EFP to connect to the EFM, but that
> doesn't seem like enough. What is the general procedure for this stuff
> to work? This also brings up the question of how do PRO SE filers get
> identified/approved with the court? 

I'm glad you're looking closely.  Our EFM is fundamentally agnostic. 
Accordingly, it doesn't care much for the content of filings, just their
form.  The paradigm, I would say, is that if it's good enough for the
clerk reviewing it, it's good enough for the EFM.  So to answer your
question, our EFM doesn't authenticate users of the EFP, only the EFP
itself.  To OpenEFM, the EFP is the user.

--Jason

--
If you are going through hell, keep going. -- Sir Winston Churchill

[Openefm-development] Authentication and Attorney Registration

[Jeremiah J. <jer...@go...>]

Dumb question here.=20

What's the standard authentication scheme for the EFP to use with the
EFM?=20

Does the court use the EFM to setup users and then the user take that
id/password to the EFP and register it? Then does it use that ip/pass
pair to insure that a filer is who they say they are? It seems that you
need more than just an ID to associate who filed what. If I find out
that atty bob's id is 12 and I register with the EFP to use id 12 when
dealing with a court's EFM all sorts of bad things could happen. When I
look at the examples and you code, I see no references to the actual
filer, nor any security to insure they are who they say they are...I do
see id/pass for the EFP to connect to the EFM, but that doesn't seem
like enough. What is the general procedure for this stuff to work? This
also brings up the question of how do PRO SE filers get
identified/approved with the court?=20



If at first you don't succeed, give up, no use being a damn fool.

Re: [Openefm-development] Re: OpenEFM question

[Jim B. <be...@co...>]

On Mar 3, 2005, at 7:16 AM, Jeremiah Jahn wrote:

> On Wed, 2005-03-02 at 14:44 -0800, Jason Van Cleve wrote:
>
>
>>
>>>> things as simple as possible.  Even SOAP, we find, is superfluous.
>>> Would you just shove the XML through a socket directly, or what?
>>
>> No, we like XML over HTTP for this stuff.  (Personally, I think the
>> existing SOAP with attachments interface is best, because that allows
>> for better handling of binaries.  But .NET has problems with it.)
>
> The last time we visited this subject, we determined that in-lining the
> data was the only platform independent way to do it. Java/SUN had one
> standard for soap with attachments and MS(VB6) had another involving
> MIME/Types or some such thing. Can't really remember the details.

Hah!  We dealt with this exact problem during the the OXCI project.  It 
was huge headache.  I'm sure Jason could expound almost endlessly on 
how annoying these issues were.

... Also ...

>
>> I'm just trying to boil down for our competitors/detractors what kind
>> of API they will be able to use with us. Since y'all seem to be the
>> biggest open source player in the field, I'd like to be able to say
>> "If we don't use OpenEFM, then we will at least adhere to their API."
>> Which brings me to another question. Who else is out their in the open
>> source EFM world worth exploring. You all make the most noise, So I've
>> been hoping to ride on your coattails a little, when dealing with the
>> BIG BOYS.
>
> Mr. Beard, can you address this?

The only other Open Source EFM that I'm aware of was implemented by the 
good folks at the National Center for State Courts.  They developed an 
EFM called inCounter.  It is a LAMP project.  The goal of inCounter was 
to develop a reference implementation, or proof of concept.  It was not 
necessarily meant to be a production system.  I am not aware of any 
continued development or support of that application.  Jim McMillan 
would be the person to speak to at NCSC about that project.  He is 
generally a good resource about these types of projects.

In general my advice would be to pick a XML specification ( 2GEFS or 
Legal XML 1.1 ) and stick as closely to it as possible.  The XML 
specification really ends up being the API since all messages are sent 
using the spec.  2GEFS is the most mature.  This will let you be able 
to tell other companies that might want to file exactly what the 
filings should look like.  Several implementations in California are 
currently being completed so the 2GEFS specifications has gone through 
deployed, real world testing.

Legal XML may soon ( 2-4 months? ) deliver a standard that would 
compete with 2GEFS.  However it will not be mature as it will not have 
undergone deployed testing.  Also it will be based on the GJXDM which 
is confusing and hard to use, to say the least..

If you decide you want to use OpenEFM we would be happy to help you in 
any way we can.


>
>>
>> --Jason
>> counterclaim
> I'll defend to the death your right to say that, but I never said I'd
> listen to it! -- Tom Galloway with apologies to Voltaire
>
Jim Beard
counterclaim.com, Inc
http://www.counterclaim.com
http://openefm.sourceforge.net
(800) 264-8145

Re: [Openefm-development] Re: OpenEFM question

[Jeremiah J. <jer...@go...>]

On Thu, 2005-03-03 at 13:29 -0800, Jason Van Cleve wrote:
> Quoth Jeremiah Jahn, on Thu, 03 Mar 2005 14:49:02 -0600:
>=20
> > > This is also our criterion for a new vs.  existing case.  Normally,
> > > party information need only be sent with the initial filing, and we
> > > have no plans for the EFM to add or update party data to existing
> > > cases. That would seem out of scope.
> > In other words you leave that up to the CMS(adapter)?
>=20
> Not necessarily.  Internally, if we see no case number, we assume an
> initial filing.  When it is accepted and sent on to the CMS, we may need
> to construct a different XML document depending on this.  The 2GEFS
> interface is not defined in terms of filings, but cases; so we have to
> send an explicit new-case message, for initial filings only.
>=20
> Now, previous version of OpenEFM, I've said, send a single filing
> package for both initial and "subsequent" filings, so in that case, the
> CMSAdapter gets an LxmlFiling object at the CMS, and it was free to do
> whatever it had to with that, add a case, parties, documents, in
> whatever order.  Because 2GEFS is breaking this one "filing" operation
> into several CMS-level operations, we may have to expand our CMSAdapter
> interface, specify it more.
>=20
> > Being in the Legal industry, The quote from our clients is that you
> > can't add a party to a case unless you submit with it a "motion to
> > amend complaint." This can also be done in court on the fly, but that
> > is obviously not an e-filing problem. I guess that would remove the
> > idea of dynamically adding litigants to a case. FYI
>=20
> Good info', stuff to which I have little access, unfortunately.=20
> Hopefully this is moot, though, and adding litigants after the fact will
> never become a requirement.  (Never say never, right?)  To me it just
> seems like a function of the CMS, altogether out of the scope of an EFM.
>  But it ain't up to me.  ;)
In our neck of the woods, Small Claims cases are the most likely for
this to happen to, but it's still rare. I believe that in Tort cases the
litigants are specified as an attachment to the case and not as a true
litigant on the case. This allows them to continually add litigants
without amending the complaint over and over.=20


>=20
> > I'm just trying to boil down for our competitors/detractors what kind
> > of API they will be able to use with us. Since y'all seem to be the
> > biggest open source player in the field, I'd like to be able to say
> > "If we don't use OpenEFM, then we will at least adhere to their API."
> > Which brings me to another question. Who else is out their in the open
> > source EFM world worth exploring. You all make the most noise, So I've
> > been hoping to ride on your coattails a little, when dealing with the
> > BIG BOYS.
>=20
> Mr. Beard, can you address this?
>=20
> > > What is meant by "if someone used the addParty method", exactly?=20
> > > The only "addParty method" in our system currently is the 2GEFS CMS
> > > API call I've begun implementing.  The XML format for that is
> > > already defined sans binary data.
> > Is that actually the way things have to be done. I would think that
> > since you can't add a party without a matching document the two should
> > travel together.
>=20
> See, this is good discussion, because I'm not even aware of any such
> requirement.  As far as OpenEFM is concerned, party definitions that
> come in with a filing are not strongly coupled with any of its
> documents.  I didn't even know there was a corresponding document for a
> party.  So we just add all the parties and all the documents, and if the
> CMS doesn't complain, we call it good.  Otherwise stated, all
> data-validity (not including XML validation) checks are performed
> visually by the clerk responsible for accepting or rejecting the filing
> at the EFM.
We would like to be in the situation, where ALL validation is done
programmatically (that should be a real word). All the court staff has
to due is look at their work queue and say okay. If they are trying to
add a party not already on a case and do not include a document of type
amend complaint, then the filer will receive an error response. The
court user would still need make sure that the litigants being added are
included in the attached document. I do believe however, that adding
litigants will be a special and rare case.=20

We are kind of Straddling the fence since we are trying to fit in
criminal e-filing^H^H^H^H^Himporting from our State's Attorney
application as well. Keeping the two straight can sometimes be a little
rough. You though in workflow to the mix and the architecture of our
whole system becomes downright insane (and that would be my job
description in a nutshell (pun intended)).=20

-jj-

>=20
> --Jason Van Cleve
> counterclaim
>=20
> --
> I knit little sweaters for my pet peeves.
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Openefm-development mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openefm-development
If you don't care where you are, then you ain't lost.

Re: [Openefm-development] Re: OpenEFM question

[Jason V. C. <ja...@va...>]

Quoth Jeremiah Jahn, on Thu, 03 Mar 2005 14:49:02 -0600:

> > This is also our criterion for a new vs.  existing case.  Normally,
> > party information need only be sent with the initial filing, and we
> > have no plans for the EFM to add or update party data to existing
> > cases. That would seem out of scope.
> In other words you leave that up to the CMS(adapter)?

Not necessarily.  Internally, if we see no case number, we assume an
initial filing.  When it is accepted and sent on to the CMS, we may need
to construct a different XML document depending on this.  The 2GEFS
interface is not defined in terms of filings, but cases; so we have to
send an explicit new-case message, for initial filings only.

Now, previous version of OpenEFM, I've said, send a single filing
package for both initial and "subsequent" filings, so in that case, the
CMSAdapter gets an LxmlFiling object at the CMS, and it was free to do
whatever it had to with that, add a case, parties, documents, in
whatever order.  Because 2GEFS is breaking this one "filing" operation
into several CMS-level operations, we may have to expand our CMSAdapter
interface, specify it more.

> Being in the Legal industry, The quote from our clients is that you
> can't add a party to a case unless you submit with it a "motion to
> amend complaint." This can also be done in court on the fly, but that
> is obviously not an e-filing problem. I guess that would remove the
> idea of dynamically adding litigants to a case. FYI

Good info', stuff to which I have little access, unfortunately. 
Hopefully this is moot, though, and adding litigants after the fact will
never become a requirement.  (Never say never, right?)  To me it just
seems like a function of the CMS, altogether out of the scope of an EFM.
 But it ain't up to me.  ;)

> I'm just trying to boil down for our competitors/detractors what kind
> of API they will be able to use with us. Since y'all seem to be the
> biggest open source player in the field, I'd like to be able to say
> "If we don't use OpenEFM, then we will at least adhere to their API."
> Which brings me to another question. Who else is out their in the open
> source EFM world worth exploring. You all make the most noise, So I've
> been hoping to ride on your coattails a little, when dealing with the
> BIG BOYS.

Mr. Beard, can you address this?

> > What is meant by "if someone used the addParty method", exactly? 
> > The only "addParty method" in our system currently is the 2GEFS CMS
> > API call I've begun implementing.  The XML format for that is
> > already defined sans binary data.
> Is that actually the way things have to be done. I would think that
> since you can't add a party without a matching document the two should
> travel together.

See, this is good discussion, because I'm not even aware of any such
requirement.  As far as OpenEFM is concerned, party definitions that
come in with a filing are not strongly coupled with any of its
documents.  I didn't even know there was a corresponding document for a
party.  So we just add all the parties and all the documents, and if the
CMS doesn't complain, we call it good.  Otherwise stated, all
data-validity (not including XML validation) checks are performed
visually by the clerk responsible for accepting or rejecting the filing
at the EFM.

--Jason Van Cleve
counterclaim

--
I knit little sweaters for my pet peeves.

Re: [Openefm-development] Re: OpenEFM question

[Jeremiah J. <jer...@go...>]

On Thu, 2005-03-03 at 10:18 -0800, Jason Van Cleve wrote:
> Quoth Jeremiah Jahn, on Thu, 03 Mar 2005 09:00:57 -0600:
>=20
> > Not sure if I like this or not. How exactly do you derive the intent
> > of the filing. Our assumption has always been the following. No Case
> > number, they must want a new case so our submitCase method is called.
>=20
> This is also our criterion for a new vs.  existing case.  Normally,
> party information need only be sent with the initial filing, and we have
> no plans for the EFM to add or update party data to existing cases.=20
> That would seem out of scope.
In other words you leave that up to the CMS(adapter)?

>=20
> > All Documents get pushed through our submitDocument method. Finally if
> > a party description is included in the data, the cms data is compared
> > and if any differences are found then our submitLitigant/Attorney
> > method is called. Does this sound correct to you or is there a better
> > way of handling LegalXML. Or is 2GEFS a better place to start?
>=20
> I'm not sure how the word "correct" applies here.  Technically, I think
> all these approaches would work.  The real question is, how do most
> court systems need it to work, and that is not a question for me, for I
> am not of the legal industry.  I was at the E-Courts conference last
> December, and from what I saw, this analysis just hasn't been done:=20
> there is no consensus.
Being in the Legal industry, The quote from our clients is that you
can't add a party to a case unless you submit with it a "motion to amend
complaint." This can also be done in court on the fly, but that is
obviously not an e-filing problem. I guess that would remove the idea of
dynamically adding litigants to a case. FYI
>=20
> > :) okay let me try and add some coherency to it...I was under the
> > assumption that the OpenEFM API was the previously mentioned four
>=20
> There really is no OpenEFM API, in fact.  OpenEFM is designed to support
> any format it needs to support, and it has always been based on one
> external interface or another.  We have a CMS API that works with our
> transceivers, but that is not the interface between the EFM and the CMS.
>  This may be confusing.
I'm just trying to boil down for our competitors/detractors what kind of
API they will be able to use with us. Since y'all seem to be the biggest
open source player in the field, I'd like to be able to say "If we don't
use OpenEFM, then we will at least adhere to their API." Which brings me
to another question. Who else is out their in the open source EFM world
worth exploring. You all make the most noise, So I've been hoping to
ride on your coattails a little, when dealing with the BIG BOYS.
>=20
> > methods. Under that assumption I was curious to know whether or not if
> > someone used the addParty method would the XML not only containing the
> > meta data to describe the new party, but also the binary data of the
> > document adding the party to a case.=20
>=20
> What is meant by "if someone used the addParty method", exactly?  The
> only "addParty method" in our system currently is the 2GEFS CMS API call
> I've begun implementing.  The XML format for that is already defined
> sans binary data.
Is that actually the way things have to be done. I would think that
since you can't add a party without a matching document the two should
travel together.


>=20
> --Jason Van Cleve
> counterclaim
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Openefm-development mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openefm-development
If a President doesn't do it to his wife, he'll do it to his country.

Re: [Openefm-development] Re: OpenEFM question

[Jason V. C. <ja...@va...>]

Quoth Jeremiah Jahn, on Thu, 03 Mar 2005 09:00:57 -0600:

> Not sure if I like this or not. How exactly do you derive the intent
> of the filing. Our assumption has always been the following. No Case
> number, they must want a new case so our submitCase method is called.

This is also our criterion for a new vs.  existing case.  Normally,
party information need only be sent with the initial filing, and we have
no plans for the EFM to add or update party data to existing cases. 
That would seem out of scope.

> All Documents get pushed through our submitDocument method. Finally if
> a party description is included in the data, the cms data is compared
> and if any differences are found then our submitLitigant/Attorney
> method is called. Does this sound correct to you or is there a better
> way of handling LegalXML. Or is 2GEFS a better place to start?

I'm not sure how the word "correct" applies here.  Technically, I think
all these approaches would work.  The real question is, how do most
court systems need it to work, and that is not a question for me, for I
am not of the legal industry.  I was at the E-Courts conference last
December, and from what I saw, this analysis just hasn't been done: 
there is no consensus.

> :) okay let me try and add some coherency to it...I was under the
> assumption that the OpenEFM API was the previously mentioned four

There really is no OpenEFM API, in fact.  OpenEFM is designed to support
any format it needs to support, and it has always been based on one
external interface or another.  We have a CMS API that works with our
transceivers, but that is not the interface between the EFM and the CMS.
 This may be confusing.

> methods. Under that assumption I was curious to know whether or not if
> someone used the addParty method would the XML not only containing the
> meta data to describe the new party, but also the binary data of the
> document adding the party to a case. 

What is meant by "if someone used the addParty method", exactly?  The
only "addParty method" in our system currently is the 2GEFS CMS API call
I've begun implementing.  The XML format for that is already defined
sans binary data.

--Jason Van Cleve
counterclaim

[Openefm-development] Specifications: Legal XML: Development of Use Cases

[Jim B. <be...@co...>]

The Legal XML ECF TC held a conference call to resolve nomenclature 
issues in regards to the Use Cases they are developing.  The discussion 
centered around whether or application components should be mentioned 
in the use cases.  The decision was made to allow generic reference to 
the system components to be made, using the term "Major Design 
Elements".  Everyone agreed that in practice use cases should not refer 
to system components, but the time constraints and prior knowledge of 
filing applications could not be ignored.

The use cases for Court Filing Blue are supposed to be completed in 
about two weeks time.

Jim Beard
counterclaim.com, Inc
http://www.counterclaim.com
http://openefm.sourceforge.net
(800) 264-8145

[Openefm-development] Re: OpenEFM question

[Jeremiah J. <jer...@go...>]

On Wed, 2005-03-02 at 14:44 -0800, Jason Van Cleve wrote:


>=20
> > > things as simple as possible.  Even SOAP, we find, is superfluous.
> > Would you just shove the XML through a socket directly, or what?
>=20
> No, we like XML over HTTP for this stuff.  (Personally, I think the
> existing SOAP with attachments interface is best, because that allows
> for better handling of binaries.  But .NET has problems with it.)

The last time we visited this subject, we determined that in-lining the
data was the only platform independent way to do it. Java/SUN had one
standard for soap with attachments and MS(VB6) had another involving
MIME/Types or some such thing. Can't really remember the details.=20

>=20
> --Jason
> counterclaim
I'll defend to the death your right to say that, but I never said I'd
listen to it! -- Tom Galloway with apologies to Voltaire

Re: [Openefm-development] Re: OpenEFM question

[Jeremiah J. <jer...@go...>]

On Wed, 2005-03-02 at 15:22 -0800, Jason Van Cleve wrote:
> Quoth Jeremiah Jahn, on Wed, 02 Mar 2005 16:06:06 -0600:
>=20
> > Is there some sample (legal)XML for each of the four transceiver
> > methods between the EFP and the EFM?=20
>=20
> First I should make clear the state of this code base.  Last December, I
> started revising OpenEFM for a new project in Sacramento, CA.  I made a
> rough draft of the requirements and sent that to the man in charge for
> review.  I also started changing the code itself, having been told the
> project was hot.  I haven't heard from anyone involved since then, and
> the whole project is now stalled.  So the code in CVS is currently
> unstable, if it runs at all, and you should opt for one of the releases.
>  None of which, unfortunately, is built around these methods:
>=20
> > addParty()
> > addCase()
> > addDocument()
> > transmit()
>=20
> This is the new 2GEFS interface, basically, that I have BEGUN
> integrating into OpenEFM.  The calls to addParty() and such are still on
> our drawing board.  Previous versions of OpenEFM are based on an
> all-at-once filing submission interface, where one message contained all
> parties and documents for the case filing; and that's still pretty much
> the way the software is coded.
Not sure if I like this or not. How exactly do you derive the intent of
the filing. Our assumption has always been the following. No Case
number, they must want a new case so our submitCase method is called.
All Documents get pushed through our submitDocument method. Finally if a
party description is included in the data, the cms data is compared and
if any differences are found then our submitLitigant/Attorney method is
called. Does this sound correct to you or is there a better way of
handling LegalXML. Or is 2GEFS a better place to start?


>=20
> So we have no samples of our own in this new format.  However, I was
> sent a handful of XML samples for the 2GEFS "Request-response" API, that
> seems to be what you're looking at.  These are in the repository, under
> "./sample/2GEFS".
Actually I got them from reading your code. Since I wasn't interested in
2GEFS I avoided those samples.

>=20
> > My Understanding of these is that they they will include the documents
> > with them that PDF whatever that init a new case or party.
>=20
> That was quite a sentence, Mr. Jahn.  If I understand you, when an
> 'addDocument()' message is sent, it will contain the binary data.  I
> believe it is to be BASE-64 encoded within the XML.
:) okay let me try and add some coherency to it...I was under the
assumption that the OpenEFM API was the previously mentioned four
methods. Under that assumption I was curious to know whether or not if
someone used the addParty method would the XML not only containing the
meta data to describe the new party, but also the binary data of the
document adding the party to a case.=20


>=20
> > Guess I would just like to see some example use cases for the
> > communication points of the app.
>=20
> No use cases yet, as far as I know.  I'm busy these days with a
> different project, so I don't expect anything to be done with OpenEFM
> soon, unless by another company (it IS open source).
>=20
> --Jason
>=20
> --
> In 2010, Microsoft Windows will be a quantum processing emulation layer
> for a 128-bit mod of a 64-bit hack of a 32-bit patch to a 16-bit GUI for
> an 8-bit operating system written for a 4-bit processor by a 2-bit
> company that can't stand 1 bit of competition.
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> Openefm-development mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openefm-development
"You are old," said the youth, "and your programs don't run, And there
isn't one language you like; Yet of useful suggestions for help you have
none -- Have you thought about taking a hike?" "Since I never write
programs," his father replied, "Every language looks equally bad; Yet
the people keep paying to read all my books And don't realize that
they've been had."

Re: [Openefm-development] Re: OpenEFM question

[Jason V. C. <ja...@va...>]

Quoth Jeremiah Jahn, on Wed, 02 Mar 2005 16:06:06 -0600:

> Is there some sample (legal)XML for each of the four transceiver
> methods between the EFP and the EFM? 

First I should make clear the state of this code base.  Last December, I
started revising OpenEFM for a new project in Sacramento, CA.  I made a
rough draft of the requirements and sent that to the man in charge for
review.  I also started changing the code itself, having been told the
project was hot.  I haven't heard from anyone involved since then, and
the whole project is now stalled.  So the code in CVS is currently
unstable, if it runs at all, and you should opt for one of the releases.
 None of which, unfortunately, is built around these methods:

> addParty()
> addCase()
> addDocument()
> transmit()

This is the new 2GEFS interface, basically, that I have BEGUN
integrating into OpenEFM.  The calls to addParty() and such are still on
our drawing board.  Previous versions of OpenEFM are based on an
all-at-once filing submission interface, where one message contained all
parties and documents for the case filing; and that's still pretty much
the way the software is coded.

So we have no samples of our own in this new format.  However, I was
sent a handful of XML samples for the 2GEFS "Request-response" API, that
seems to be what you're looking at.  These are in the repository, under
"./sample/2GEFS".

> My Understanding of these is that they they will include the documents
> with them that PDF whatever that init a new case or party.

That was quite a sentence, Mr. Jahn.  If I understand you, when an
'addDocument()' message is sent, it will contain the binary data.  I
believe it is to be BASE-64 encoded within the XML.

> Guess I would just like to see some example use cases for the
> communication points of the app.

No use cases yet, as far as I know.  I'm busy these days with a
different project, so I don't expect anything to be done with OpenEFM
soon, unless by another company (it IS open source).

--Jason

--
In 2010, Microsoft Windows will be a quantum processing emulation layer
for a 128-bit mod of a 64-bit hack of a 32-bit patch to a 16-bit GUI for
an 8-bit operating system written for a 4-bit processor by a 2-bit
company that can't stand 1 bit of competition.

[Openefm-development] Re: OpenEFM question

[Jeremiah J. <jer...@go...>]

Is there some sample (legal)XML for each of the four transceiver methods
between the EFP and the EFM?=20

addParty()
addCase()
addDocument()
transmit()

My Understanding of these is that they they will include the documents
with them that PDF whatever that init a new case or party.

Guess I would just like to see some example use cases for the
communication points of the app.
-jj-


... But if we laugh with derision, we will never understand. Human
intellectual capacity has not altered for thousands of years so far as
we can tell. If intelligent people invested intense energy in issues
that now seem foolish to us, then the failure lies in our understanding
of their world, not in their distorted perceptions. Even the standard
example of ancient nonsense -- the debate about angels on pinheads --
makes sense once you realize that theologians were not discussing
whether five or eighteen would fit, but whether a pin could house a
finite or an infinite number. -- S. J. Gould, "Wide Hats and Narrow
Minds"

[Openefm-development] Re: OpenEFM question

[Jason V. C. <ja...@co...>]

Quoth Jeremiah Jahn, on Tue, 01 Mar 2005 14:27:54 -0600:

> I had some difficulty getting on the mailing list, So I'll just ask
> directly.

What trouble did you have?  We want to stimulate this list a bit, so we
would help you get onto it.

> Do you have any idea what the major EFP players want to use as far as
> a SOAP API? Do you have any who are connecting to OpenEFM yet?

Here's some text from my superior in regard to that:

"The EFP players . . . tend to use what ever they have to 
for any project.  As far as what they want to use, some want minimal 
transactions and some want complex, ubl based transactions.  The 
OpenEFM is currently used in various production environments, but we 
have not been directly involved with all of them.  Most of these 
projects involve only a courts IT department and no 'big players'.  
Currently it is used in Nebraska and Guam."

> Is it true that I can just point a transceiver to our SOAP
> CMS-interface and implement add Case/Party/Document and call it a day?

We have a SOAP transceiver that includes an OpenEFM-side component and
also an optional CMS-side component.  For the EFM, you just need to
specify the right transceiver in the config' file.  For the CMS, you
might deploy the CMS-side component in (or as) a Java Web app',
specifying in your "web.xml" a servlet that will receive the SOAP/HTTP
calls from OpenEFM and send back confirmation messages, etc.  The last
mile (the hardest), is writing to our CMS-side API:  which is OpenEFM's
CMSAdapter interface.

However, if you have already developed a SOAP transceiver that conforms
to one of OpenEFM's SOAP interfaces, then yes, pointing the EFM thither
should work, and there's no need to implement anything else.  Note that
these interfaces usually involve an asynchronous callback message from
the CMS transceiver to the OpenEFM.

We also have an RMI connection implementation, which works much like the
SOAP interface.

> Does OpenEFM handle more than just LegalXML? The code looks like it
> does, but I haven't managed to find where the decesion is made as to
> what kind of trans port is being used. 2GEFS/LXML/whatever...

OpenEFM is designed to be integrated with a variety of systems.  It
currently supports versions of the 2GEFS spec' and the OXCI interface of
last year (which never actually solidified).  Other interfaces can be
implemented as well.  Which one is determined at runtime based on
OpenEFM's main configuration file, "config.xml".

> Why does the LxmlResponse have both code/text and content? Is it your
> intention that the CMS modify the the sent LXML to include the
> confirmation header or the the EFP just use the error codes that you
> sent back? There seems to be a little redundancy here. I've seen the

It was the OXCI group's on-again, off-again idea, in fact.  (We prefer
simplicity.)  Last year, LxmlResponse went back and forth between
carrying a complete XML document to just carrying a response code and
message, depending on what sort of response it encapsulated.  So we have
both for flexibility.  I believe that in the current OXCI
implementation, the responseText field is used for synchronous
"acknowledgement" messages, and the content field stores a complete
filing confirmation XML message when the CMS sends one.  This changed a
lot during our work with the OXCI group, because they simply couldn't
pin down their SOAP interface.  So what you see is a result of a very
volatile set of requirements.  If the whole 'transport' package seems
too complex, it's because I've been trying to make it as flexible as
possible.

Hope that's helpful.

--Jason Van Cleve
counterclaim

[Openefm-development] CCMS: California Case Management System

[Jim B. <be...@co...>]

As you might be aware, California is having a state wide case 
management system developed.  The project is dubbed CCMS.  CCMS is 
being developed as a Java based web application.  CCMS is not planned 
to be in use until 2009.   After speaking with persons involved in the 
development of this project I have come to a sort of understanding as 
to their approach towards an integrated EFM.

California is wisely basing all communication protocols on the 2GEFS 
specification that they developed.  As such, courts using the CCMS will 
be able to receive 2GEFS compliant filings.  The company developing the 
CCMS will be incorporating an EFM and a clerk review module.  They view 
these as different components.  The EFM will be a simple validation 
based acceptance / rejection module.  It will be implemented as a Java 
web application, intended to be hosted under Jakarta-tomcat on a 
Solaris system.  The EFM will validate incoming filings against the 
2GEFS schemas and provide a synchronous received or rejected message to 
the EFSP.  The filing will then be handed off to the CCMS.  The clerk 
review of the filing will happen from the CCMS interface.

There are a few things to take from this, first, our EFM does all that 
they require.  It might have to be tweaked a bit to meet their needs, 
but if they wanted to use OpenEFM a lot of their work would already be 
done.  This leaves me feeling encouraged.  Even though the CCMS 
developers may not have used OpenEFM ( yet? ) it still demonstrates 
that our design and approach are sound.

Jim Beard
counterclaim.com, Inc
http://www.counterclaim.com
http://openefm.sourceforge.net
(800) 264-8145

[Openefm-development] Specification Update: Legal XML

[Jim B. <be...@co...>]

Day 2 of the face-to-face was just concluded.  The item that was 
discussed that I thought was noteworthy had to do with electronic 
service.  Legal XML seems to be under the belief that electronic 
service should be conducted during all filings.  This is a good ideal 
but possibly naive.  In the Court Filing Blue use cases they discuss a 
court maintaining a service list for all case parties.    When a final 
confirmation of a filing is sent to an EFSP they envision the service 
list being sent along with it.  Thus allowing the EFSP to serve parties 
electronically when applicable and to tell filers which parties they 
will be responsible for serving in traditional ways.  This sounds fine, 
however most courts currently do not maintain the services lists.  This 
would require courts to implement some form of service list into their 
CMS.  Because of this I do not feel that it will initially be embraced 
by courts.  Some courts also designate the responsibility of 
maintaining a service list to one of the case parties.

Jim Beard
counterclaim.com, Inc
http://www.counterclaim.com
http://openefm.sourceforge.net
(800) 264-8145

[Openefm-development] Specifications: Legal XML Update

[Jim B. <be...@co...>]

Howdy,

	I just got done participating in the phone call in portion of the 
Legal XML Electronic Court Filing Technical Committee face-to-face 
meeting.  The current meeting is happening in Salt Lake City.  They are 
solidifying use cases for the Court Filing Blue.  I found two items 
discussed to be noteworthy.
	First, they decided that filing fees will only be able to be obtained 
by a court CMS.  Therefore a filing application will have to query a 
court with the filing information and get the fee information back in 
the response.  2GEFS covers this info in the Court Policy files, but 
Legal XML does not like that solution.  They spoke a fair amount about 
the filing fee being the responsibility of the filing party, which I'm 
not sure I agree with.  There was mention of filing parties being 
responsible for filling in a filing fee field in a filing interface.  I 
think the Legal XML solution will require greater work to implement, 
and the thought of a filing party being able to arbitrarily state their 
assessed fee seemed troublesome.
	Second, they mentioned being able to submit filings without a 
document.  The purpose of this would be to allow fees to be payed 
through a filing interface.  I like this concept.  It would allow fines 
assessed by the court to be collected in the same way a filing is.  
Technically there isn't much of a difference in the process ( same data 
set, etc.. ) but the verbiage and interface might have to change a bit 
to accommodate it.

Jim Beard
counterclaim.com, Inc
http://www.counterclaim.com
http://openefm.sourceforge.net
(800) 264-8145

[Openefm-development] Re: Counterclaim / OpenEFM

[Jim B. <be...@co...>]

Po,

	I don't mind the questions at all, and thank you for the help that you 
have provided over the EUG-LUG list.  We have been using FogBugz now 
since is was asking about it and found it to do everything I wanted.
	
	About our company;  FastLAW, a case management system for courts, has 
been our flagship product.  We have installed the system in several 
Native American tribal courts.  OpenEFM has brought us a fair amount of 
media and industry attention.  Various courts have or are using it, 
however we don't hear from all of them since we release it as open 
source.  We are currently focused on the next version of our portal 
application.  We have renamed it CourtPASS.  CourtPASS is designed to 
integrate with several EFMs which would represent courts.  OpenEFM is 
intended to be integrated with the court's case management system.  
This allows filing to be created at our portal ( or a competitors ), be 
sent to an EFM, and then eventually be placed in a court's case 
management system.

	You are correct that we have been focused on the legal process 
primarily for courts.  We hope to offer our portal services to law 
firms in the future.  OpenEFM is rather versatile and could easily be 
re-configured to work in a number of different industries.  It is 
really just a way of queueing up a bunch of XML based filings and 
requiring acceptance or rejection of the filings.  It does not 
necessarily need to be fully integrated with a back end system, 
although the back end integration delivers much greater value.

	If you are interested in the intersection of law and software then I 
would suggest taking a look at GJXDM.  GJXDM stands for the Global 
Justice XML Data Model.  There is a link to their site from our OpenEFM 
home page.  GJXDM is sponsored by the Department of Justice and is 
meant to be an XML foundation for all integrated justice projects, 
these include LEOs, courts, DAs, prisons, etc...  GLXDM is large and 
complex, possibly even overly so.  It does however have DoJ backing, so 
it is getting some traction.  The Second Generation Electronic Filings 
Standards (2GEFS) was developed by the state of California to handle 
court XML transactions.  It is much simpler to use and has superior 
documentation in my opinion.  However it is not intended to be used for 
non-court specific tasks.  There is also a link to this off of Open EFM 
home page.

Let me know if there is anything else I can answer for you, and 
remember that OpenEFM is an open source project, so depending your 
interest level you are free to get involved!

Thanks,
Jim

On Feb 14, 2005, at 2:00 PM, Po Petz wrote:

>
> Hi,
>
> I don't know if you remember but a couple months ago I helped you with 
> that perlcgi module question you posted to the EUG-LUG and I also 
> suggested FogBugz and a couple other packages when you asked about 
> issue tracking software.
>
> I had a few questions about Counterclaim that weren't readily apparent 
> looking at the website.  Mostly I was trying to distinguish what seems 
> to be the flagship product, OpenEFM, and the portal system, the Public 
> Access Server, which I presume works with the OpenEFM.  Is that even 
> remotely accurate or did I completely misunderstand the online 
> collateral?
>
> Also, Counterclaim seems focused on legal process automation tools 
> primarily for courts: filing, case management, recordkeeping.  This is 
> in contrast to law firms, whom I presume have money for fancy custom 
> document management systems.  But what about law enforcement groups?  
> Would OpenEFM work for those groups or is there a different specific 
> market for that segment as well?
>
> I hope you don't mind my questions.  For the past few years I've been 
> nurturing an interest in the intersection of law and software 
> technology.
>
> thanks,
> -po
>
>
Jim Beard
counterclaim.com, Inc
http://www.counterclaim.com
http://openefm.sourceforge.net
(800) 264-8145

Re: [Openefm-development] Re: OpenEFM and PDF Stamping

[Jason V. C. <ja...@va...>]

Quoth Jim Beard, on Wed, 5 Jan 2005 10:48:21 -0800:

> So to integrate this way we would need to develop the correct Adobe 
> JavaScript to point to our SOAP web service.  We would also need to 
> implement the SOAP web service which receives the stamped filings.

This adding "Adobe JavaScript" business seems dubious.  Better if we
didn't have to modify the PDF at all upon reception.  Here are two
alternative ideas:

1. Add a URL-query-string parameter to our URL for the PDF.  Maybe
Acrobat can extract and use that value as a return address URI.

2. Have Acrobat submit the modified file to the same URI that served it.

Not sure if these'll work, but there they are.

--Jason

--
Remember this lesson from cartoon TV:  if you ever accidently run off a
cliff, don't look down.