RE: [legalxml-courtfiling] Groups - Component Issue resolution conference call added

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] Groups - Component Issue resolution      conference call added

From: "Cabral, James E." <>

To: <>,<>

Date: Sun, 27 Feb 2005 15:53:45 -0800

Scott,

 

Unfortunately, "Filing Assembler" and "Filing Reviewer" 
sound an awful like the persons (lawyers or legal assistants and 
clerks) performing these functions.  

 

  
jim

From: Scott Came 
[mailto:]
Sent: Sunday, February 27, 2005 
2:52 PM
To: 

Subject: RE: 
[legalxml-courtfiling] Groups - Component Issue resolution conference call 
added

James, I think we might be close, but again we're getting tripped up 
by terminology...

If I understand your comments below, you are 
essentially allowing for:

1. A "filing client" that allows filers to 
assemble filings
2. A "filing server" or "filing system" that receives 
filings at the court and allows clerks to review them
3. A case management 
system at the court that needs to receive some of the data about filings (I 
would add that typically you'll need document management and other system 
interfaces here too, but at the September F2F we decided to put this all behind 
one single interface and let the implementer figure out how to do it)

You 
call these "entities," in the intial use cases we called them components...it 
doesn't matter terribly much what we call them. We should pick a term and move 
on.

The important thing is, these are independent implementations of 
three separate interfaces. (This isn't an "imagined" scenario...it is in fact 
the primary scenario we've been envisioning on the TC...TC, correct me if I'm 
wrong.) I agree 100% with your comment that describing the interfaces to these 
three components/entities (in an unamiguous, implementable way) is what Blue 
should do.

This is not to say there aren't customers out there who would 
prefer to purchase all three "entities" from the same vendor, and have it all 
hard-wired together. We're just not assuming that to be the desire in all 
cases.

Note that there need to be interfaces (APIs) to all three 
"entities", not just #2. As we've seen, there is asynchronous communication 
going both ways into and out of #2. So "entities" #1 and #3 both need to have 
APIs defined.

The idea behind the current terminology is this... A 
component is something that I build or buy that implements a part of the Blue 
specification. An interface is that "part"...it's the standardized set of 
functions that a component must provide to be conformant with the specification. 
We needed a generic term for things that implement an interface...component 
seemed to fit. If there's a better term, we should switch (though I'm not wild 
about "entity".)

Now, in terms of naming the "entities"... I sensed a 
consensus at the December meeting that the TC was pleased to discard the old 
term Electronic Filing Manager (EFM), because it's not descriptive of that 
"entity's" function. It doesn't really "manage" anything. It receives filings 
and presents them to clerks for review. So we changed the name to "Filing Review 
Component." In my view, "Filing System" is even more generic and undescriptive 
than EFM. I guess we could live with "Filing Client", although again that is 
pretty undescriptive...the idea is that it's the "entity" where filers assemble 
filings. So Filing Assembly Component sounds pretty good. One further caution: 
"Client" and "Server", at least to techies, imply a particular architecture that 
I don't believe we want to suggest.

(TC: if I'm wrong about the consensus 
I sensed in Las Vegas, please let me know.)

What about: Filing Assembler, 
Filing Reviewer, and Court Record Adapter? That way we get "Component" out of 
the name, and we can all conceptualize these terms in whatever way suits us: 
components, entities, thingeys, whatever.

Thanks.
--Scott

Scott 
Came
President and Principal Consultant
Justice Integration Solutions, 
Inc.
Olympia, Washington
360-402-6525

http://www.justiceintegration.com

> 
Folks,
>
> I would just like to state my preference in resolving 
this. I would
> prefer not to see any use of the term component or a 
substitute. I would
> prefer that the standard define the functionalities 
of a generic filing
> system and an interface (API) to that system. The 
decomposition of the
> system into components is a step for the 
implementer to take not
> something for the standard to define. I would 
like to see the standard
> talk about a filer (or filing client) and a 
filing system (or server). I
> can imagine a scenario where diverse filing 
clients talk to diverse
> filing systems which may implement the standard 
interfaces in diverse
> ways. It may be necessary to discuss a CMS as 
well. This might be seen
> as another client or a cooperating server. With 
these three entities I
> think a useful standard could be described. 
Additionally, it might be
> useful to describe the interface to a payment 
system (another server).
>
> Looking forward to the 
discussion.
>
> Regards,
> james
>
>