RE: [courtfiling-reqts] Groups - LegalXML Blue Requirements Final Draft (wd-LegalXML-Requirements-08.doc) uploaded

["Rex McElrath" <mcelratr@gaaoc.us>]

Hi,

  Thank you very much to those who have worked on this document.  I
think it is a good document, but it could be better.  In general, most
of my comments are around asking for the some areas of the use cases to
focus on the points of interaction between external systems and not on
the internal workings of closed systems.  We have to get beyond the old
methods that simply replace the courier and postman to make a
specification useful and not obsolete before it is written.  This
specification is strictly focused on electronic filing, but as soon as
e-filing is initiated, even semi-wide spread, the federal and state
governments are going to be asking for more data exchange.  If this
specification can be geared in that direction, we are ahead of the game,
as our specification could naturally lead into data exchange by having
the proper mechanics in place.  If it is not, then we have spent a
tremendous amount of time and energy on an effort that will be bypassed
by others that will come up as defacto standards for courts when courts
are required to share data.  It seems that we are teetering on the edge
of making a specification that could translate into data exchange with a
solid background for schema and web services, but are not quite there
yet.

 Below are my comments:

*	285-356 - Can be automated, should be optional, and shouldn't be
a part of this spec.  We should not be building the internal systems and
should not care about them for this spec.  We need to concentrate on
interoperability.  It does not matter how the clerk reviews or dockets
the information as long as the information from that process gets passed
back and forth in a means that the other side can understand.
*	360: This can be automated.
*	363: Optional.  "Presented" implies human review by presentation
of the data and not sending and processing by a machine.
*	377: Or machine
*	378-447: Needs to be stricken or moved to appendix of "Further
integration that is not part of the standard, but is possible to use
with the standard."  Again, we should not need to care about internal
operations, just the touching points between two entities.  If this is
an electronic service provider that has to send documents to a court, if
that provider is the only provider for the court, then it is a closed
system and does not need a standard transmission method. If an EFSP
needs a way to file from EFSP into the court such that the court can use
any EFSP and they will all be sending the same types of messages, then
that needs to be specified and put in as an optional extension for
"intermediary communications in e-filing" and not included as part of
the core specification that is a requirement to be fully compliant with.
*	451: person or machine interacting with the . . .
*	491: Or notice of no changes to content.  Unless false "visible"
stamps are used, this shouldn't be an issue with electronic signatures
in use.  Mandating this causes unnecessary network traffic, processor
use, and disk space utilization.
*	509 : Or Machine
*	540: Assumes abstraction of paper based world.  Needs to be
optional or have option of no change indicator substitution for sending
entire contents back to filer.
*	578: "presents" should read "sends."  Past the transmission and
communication points, there isn't a need to specify internals of the
black boxes.  Someone at an authorized system, could have an automated
request set to check for calendaring information or other information
that the specification does not need to deal with how presented, just
the transmission of the information.
*	584: user, machine, or entity
*	619-620: Or other explanatory error message.  A denial of access
means something completely different than "No record found."  No record
found is a general cover all, but what about the option to return an
error code and/or error text?
*	664:  The persistence needs to be optional, otherwise our
standard is merely a validation for vendors with EFSP like systems and
not progress forward.  For automated systems that pass the information
on, there is no need to "persist" data at the receiving process.  If
this is a true web service and an abstraction of an existing system, the
receiving process merely intakes and passes off.   For example, the
receiving process could validate, the backend system could validate, or
an intermediary system could validate the message.  Since we are dealing
with the external points of interaction, we, as a group, really should
not care where it takes place inside the black box unless it interferes
with the communications going back to the other system.
*	719: Optionally provides an interface.  For agencies and law
firms with case management systems, they do not need to have to leave
their main system to interact with a filing system.  Almost all modern
systems have and SDK or API that allows for modifications to the system
to add new features.  Even closed systems like Microsoft allow
extensions for Office to be created.  Adding in a mandatory interface
here brings the spec back inside of a black box where it does not need
to be.
*	759-764: This section does not need to be specified.  We do not
need to create standardized "Docketing Response", other wise we have
forced an unnecessary internal convention on systems, therefore this
seems unnecessary information for the use case.
*	768-771:  So they are playing hot potato with the "Filing
Receipt"?  Are they sending the same information back and forth to prove
they received it? Or  Is the second "Filing Receipt" in #9 a
confirmation that the Clerk Review's Filing Receipt was received by the
Filing MDE?  If the latter, then this make sense.
*	791-802:  I can see having these steps in the use cases for
explanatory purposes, but I have to strongly object to specifying a
"Docketing Response" as the specification progresses, if that is the
intention of including them here.  The communications with the Case
Management systems will take the form of everything from a proprietary
3rd party e-filing service provider sending secured formatted messages
to individual courts to RPC, RMI,  JDBC/ODBC, or other software calls
from a front end system to a back end system.
*	833: Have we not gotten over forcing the required use of an EFSP
yet?  There is no need for this "MDE" to be required to persist data or
documents.  Yes, it could, but it does not need to be in the
specification that it has to.  More likely, the front end "Filing MDE"
will pass the receipt back to either a document management or a case
management system that will make the receipt available to the user(s) at
a later time.
*	846-890:  This needs to be stricken unless for hypothetical
purposes.  This scenario does not need to be furthered into parts of the
specification.
*	894:  Optionally, it does not have to "present" to a human to
communicate between systems, therefore this is unnecessary.  It may do
this or anything else that the system designers desire it to do, but it
does not need to be a requirement of this specification that it does.
*	900-901:  Needs to be stricken, unless only for explanatory
purposes and not part of the specification.  This falls in the realm of
the black box to specify actions between a front end system and a back
end system.
*	904:a court staff member or court controlled machine(s).
*	937-938:  This is specifying in the black box again and needs to
be taken out.
*	954-1062:  I have to urge the group to take this section out as
it is inappropriate for the specification.  Add in failure to docket a
record as an extension of filing or clerk review to enable a graceful
failure of the communications, but specifying the docketing interactions
is far into the black box and off course in trying to write a
specification for interactions between external systems.  A court or
vendor can write what ever they wish to allow connections to the courts.
Unless it interacts with other systems or opens a court to receive
service by multiple vendors, this seems illogical to specify.  From
vendor to court is a closed system.  From vendor acting on behalf of
court to filer is open and should be part of the specification under
"Transmit Message" or "Filer files a Filing".
*	1169:  This seems to require the court to be the filer's book
keeper.  This should not fall under the courts liability.   The court is
able to produce documents in a case, but should not be required to keep
the records for filings rejected, when, why, etc for the filers.  It is
the filer's responsibility to keep their own records.  If a vendor wants
to do this for a filer as a bonus, sure, there is nothing prohibiting
that, but this should not be part of the specification.
*	1265: Is this like a bulk query for something like "all cases
where "x" was involved as a defendant? 
*	1316:  Why not make this an extension of get case?  Is this
where a filer can query for a standardized form for the court?  If so,
then this is useful.  If not, then it seems more appropriate as an
extension to "Get Case" as a query for a document related to a specific
case.
*	1392-1398:  Should be two scenarios.  1) Calculate fees based on
document type or declared characteristics  and 2) Calculate fees based
on document specifics from processing of document.  For scenario 1,
courts would use very little bandwidth and processing power, and this
query would give back fees quite quickly and simply with small efficient
messaging.  For scenario 2), courts can run through any type of
processing that they want for the full document to determine fees, but
since courts have the choice of 2 scenarios, the documents do not always
have to be transmitted twice which would help out courts with low
bandwidth connections and conserve processing efficiency for high volume
courts and high volume filers.
*	1666:  Why not "later resending"?  If retrieval, then
essentially, the court will have to have a "mailbox" for the person to
check for messages.  If sending, then it can go back to the filer when
the filer is ready to receive or go out of band to the filer by non
electronic means if their system completely fails and does not come back
online.
*	1735: "Can click on the seal"?  Does this indicate a visible
seal in the document, or is this similar to clicking on the lock sign,
or certificate icon at the bottom of Internet Explorer or Adobe Acrobat
to check the validity of a document?  If the latter, this is good.  If
the former and a visible seal, this leads to double document storage and
defeats the document integrity requirement.   Do not believe that it is
the former, but wanted to make a note about this.
*	1769-1788: This needs to be deleted.  This is nice if we are
specifying software, but we should not be in that realm at all.  Our job
should be to specify standards for data transmission and communication,
not to architect out specific software modules.  We are deep inside the
black boxes again and need to pull out of that area.  For the
specification to be successful and to not validate any specific way of
doing things inside a particular software, the black boxes should be
left alone.


I do think the work on this is coming along, and I really appreciate
those who are working on this.   


Thank you,

Rex McElrath
244 Washington St. SW
Suite 300
Atlanta, GA 30334
404-657-9218

-----Original Message-----
From: etingom@tsquaredinteractive.com
[mailto:etingom@tsquaredinteractive.com] 
Sent: Monday, April 04, 2005 11:55 PM
To: courtfiling-reqts@lists.oasis-open.org
Subject: [courtfiling-reqts] Groups - LegalXML Blue Requirements Final
Draft (wd-LegalXML-Requirements-08.doc) uploaded

The document named LegalXML  Blue Requirements Final Draft
(wd-LegalXML-Requirements-08.doc) has been submitted by Eric Tingom to
the
LegalXML Court Filing Requirements SC document repository.

Document Description:
Important notes: 
1. Latest version of Blue Requirements. 

2. I am working on Blue Specifications

3. Please have all comments on these documents completed by April 18th,
2005 by 5:00 p.m. -7 G.M.T. Any comments received will then be
incorporated
before the vote.

Thank you for your participation and support of Blue 

Eric

View Document Details:
http://www.oasis-open.org/apps/org/workgroup/courtfiling-reqts/document.
php?document_id=12117

Download Document:  
http://www.oasis-open.org/apps/org/workgroup/courtfiling-reqts/download.
php/12117/wd-LegalXML-Requirements-08.doc


PLEASE NOTE:  If the above links do 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.

-OASIS Open Administration


-----------------------------------------
This e-mail and any files transmitted with it are intended solely for the
use of the entity or individual(s) to whom they are addressed and not for
reliance upon by unintended recipients.  If you are not the intended
recipient or the person responsible for delivering the e-mail to the
intended recipient be advised that you have received this e-mail in error
and that any use, dissemination, forwarding, printing, or copying of this
e-mail and any files transmitted are strictly prohibited. If you have
received this e-mail in error please delete the entire email and
immediately notify us by email to the sender or by telephone to the AOC
main office number, (404) 656-5171. Thank you.