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: "Scott Came" <scott@justiceintegration.com>
- To: legalxml-courtfiling@lists.oasis-open.org
- Date: Sun, 27 Feb 2005 14:52:24 -0800 (PST)
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
scott@justiceintegration.com
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
>
> -----Original Message-----
> From: robin.gibson@courts.mo.gov
[mailto:robin.gibson@courts.mo.gov]
> Sent: Friday, February 25, 2005 6:20 PM
> To:
legalxml-courtfiling@lists.oasis-open.org
> Subject: [legalxml-courtfiling] Groups - Component Issue
resolution
> conference call added
>
>
> Component Issue resolution conference call
has been added by Ms Robin
> Gibson
>
> Date: Wednesday, 02 March 2005
> Time:
04:30pm - 05:30pm ET
>
> Event Description:
> To resolve the nomenclature issues of component
in the development of
> requirements for Blue.
> Pending conference call setup.
>
>
Agenda:
>
>
> Minutes:
>
>
> View event details:
>
http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/event.
> php?event_id=7196
>
> PLEASE NOTE: If the above link does not work for you, your email
> application may be breaking the
link into two pieces. You may be able
> to copy and paste the entire link address into the address field of
your
> web browser.
>
>
> To unsubscribe from this mailing list (and be removed from
the roster of the OASIS TC), go to
>
http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/members/leave_workgroup.php.
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]