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: "Cusick, James" <>

To: <>,<>

Date: Mon, 28 Feb 2005 14:42:22 -0500

Scott and all,

 

Thanks for understanding my comments and replying 
in such detail. Clearly, I do not want to substitute one term for another 
without good cause. My primary comment centers on the structure of the messaging 
interfaces that will be required in the standard. I think that the messaging 
should be primarily defined between a "filer" and a "blue filing system". 
As for the components that are currently well understood by the TC, I would 
say that if the top level messaging interface is defined well then there would 
be no need for the drill down components as they are an implementation 
concern not a standards level concern. As for the CMS or document management 
system or payment system I see no reason that interfaces for these 
objects/entities/systems could be additionally developed under this 
approach.

 

By the way, I think the "filing assembler" term 
is not fully descriptive of what the filer must do. In my view the filer would 
assemble and submit filings as well as check on status, do reporting, etc., 
thus, the more general term of "filer" seems to make sense. Similarly, I think 
the current components of "filing reviewer" and "court record" could be 
subsumed by the general term of "blue filing 
system".

 

As for moving on, I am totally supportive of making a quick 
resolution and proceeding with the TC's opinion. 

 

Regards,

james

 

 

  

  
  From: Scott Came 
  [mailto:]
Sent: Sunday, February 27, 
  2005 5: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
>
>