[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [courtfiling-reqts] Groups - LegalXML Blue Requirements Final Draft (wd-LegalXML-Requirements-08.doc) uploaded
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: firstname.lastname@example.org [mailto:email@example.com] Sent: Monday, April 04, 2005 11:55 PM To: firstname.lastname@example.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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]