legalxml-courtfiling — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
Re: [legalxml-courtfiling] Apologies and follow-up to Jan 6th 2004 conference call
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] Apologies and follow-up to Jan 6th 2004 conference call
- From: "Dallas Powell" <[email protected]>
- To: <[email protected]>
- Date: Wed, 7 Jan 2004 15:28:55 -0700
Here are some additional thoughts -
Dallas
> <You will note that through these expressed
thoughts i continue my thread of discussion from 2003 as to how the TC will
finally resolve the question of maintaining a Court Filing sub-committee called
Court Document given the focus of the committee's wo
> rk to date is on basic court filing methods to accommodate any "payload".>
>
> Thought #1:
> On December 7th the TC received a public comment from [email protected]: "Would the committee be coming out with an XML Schema as against a DTD which is presently under review (as I understand)? "
>
It is my understanding that from our face-to-face meeting in Georgia we agreed that Court Document is a valid committee, but it is most likely that the majority of documents that are generated will conform to and extend GJXDM document instances. As part of that discussion it was suggested that the number of attorneys that are willing to change their methods of creating documents to utilize XML is low, however documents that are generated from custom interfaces and database outputs are highly likely to support XML. A good example is LA Sheriff's office and the work they are doing.
> rk to date is on basic court filing methods to accommodate any "payload".>
>
> Thought #1:
> On December 7th the TC received a public comment from [email protected]: "Would the committee be coming out with an XML Schema as against a DTD which is presently under review (as I understand)? "
>
It is my understanding that from our face-to-face meeting in Georgia we agreed that Court Document is a valid committee, but it is most likely that the majority of documents that are generated will conform to and extend GJXDM document instances. As part of that discussion it was suggested that the number of attorneys that are willing to change their methods of creating documents to utilize XML is low, however documents that are generated from custom interfaces and database outputs are highly likely to support XML. A good example is LA Sheriff's office and the work they are doing.
> Suggest: separate initiative either as
part of the Court Filing TC or through a proposal to the LegalXML section to
create a separate TC for Electronic Preparation Provider spec
development??
> i realize this suggestion does introduce administrative decisions with regard to other legal document initiatives (e.g. contracts) and rises the topic of >interoperability.
>
> Re: The EFP= front end application that prepares and submits filings . The EFP is the application on the filer's side of the e-filing architecture also called the client. Is there a LegalXML recommendation, model for authoring the "payload" of all co
> urt filing types? where does this scope of work intersect with Blue vision?
> i realize this suggestion does introduce administrative decisions with regard to other legal document initiatives (e.g. contracts) and rises the topic of >interoperability.
>
> Re: The EFP= front end application that prepares and submits filings . The EFP is the application on the filer's side of the e-filing architecture also called the client. Is there a LegalXML recommendation, model for authoring the "payload" of all co
> urt filing types? where does this scope of work intersect with Blue vision?
Such a suggestion would push
the committee in designing applications which is not in the scope of this
standard. The envelope and communication interoperability challenges
are going to challenge this committee already without adding concepts of
preparation.
> The Transcript TC states: The purpose of this TC is to develop an XML compliant syntax for representing legal transcript documents either as stand-alone structured content, or as part of other legal records.
> Shouldn't an "off-spring" of Blue be a TC or a Sub TC under Court Filing that constructs an XML compliant syntax for representing court filing documents authored by Court customers (e.g. attorneys)? Is there a need from such a specification?
>
It is my opinion that this TC should be part of court
documents TC.
>
> Thought#2 The Open Extensible Mark-up Language (XML) Court interface is defining its architecture data classes for an Electronic Filing Manager: Filing; Confirmation; Query; Response; Policy.
>
> Is the OXCI 2004 initiative considered by theTC members to be a Blue implementation?
In the Las Vegas face-to-face meeting it was recognized
that OXCI is not a base-line to the standard. My understanding is that it
is Georgia's and Washington's attempt at creating an EFM that will conform
to the standard. If Georgia and Washington push OXCI to
completion before Blue is completed and voted on could cause they to be non
conforming in their first release, but that is not unusual in developing
standards. How do you conform if the standard is not complete.
Hopefully, OXCI will be able to supply value back to the development of
Blue.
In reverse the OXCI documentation points to Blue compliance... Can someone
please clarify for me the intended action plan for Blue development and how that
supports OX CI or how OXCI development supports Blue specification
creation?
We anticipate that OXCI will create a schema to move
forward with in January 2004 according to what was presented in Las Vegas.
Whether the schema will work for Blue or not is yet to be
determined.
>
> As i understand it: OXCI is a state court initiative and Blue is a set of standards to be applicable to any court setting..??
>
> Thought#3: Blue's vision is a set of specs that enables exchanges of court filings and related court filing information among courts, their partners and customers.
>
> Is the Blue vision considering exchanges of court filings/notice in
any court setting (e.g. federal,state) meaning a wide spectrum of specifications
within a defined core set or is Blue 2004 to be a set of specs based on one
"model" of court information
> data exchange?
> data exchange?
It is my understanding that part of the principles of
Blue to be of value to all courts, at least within the US and Canada.
There was some discussion in the Las Vegas meeting about how to make Blue of
value for all courts through out the world, but that did not seem to capture
much support. I recommend that if there are people listening, they push
their input into the Concept Document of Blue.
>
> Does the Blue vision of filing court case documents include an interoperability component to interface with Electronic Filing Providers (open source based or proprietary based technology)?
>
It is the intent of the Interoperability group to make
sure that this happens. That is why we included envelope,
communications/messaging, and security in the concept document.
> Thought#4 Performance/Testing...
> i think we had developed documentation that maps requirements from a TC perspective... perhaps this topic can be revisited as an agenda item during one of the 2004 meetings.. in association with Blue development. recent resources on the XML performance
> topic through the e-Gov TC thread have come to my attention and might be helpful when considering Blue development.
>
>
> I appreciate TC members taking time out to send me responses to one or more of my inquiries or pointing me to existing TC documentation that addresses my inquiry.
> Look forward to continued productive, conclusive discussions as Court Filing TC initiatives move forward in 2004.
>
> thanks for allowing me to participate in this TC over these past years... diane
>
>
>
>
>
>
>
>
> >>Outlook Object<<
> Subject: RE: [egov] Re: Need advice regarding XML performance issues
>
>
> Dear Mr. Hughes, Duane
>
> As Duane says there are different aspects of "performance" in XML parsing and processing.
> You might want to look at the attached XML Performance Test report and the stress curve picture.
>
> The report and further information can be found at:
>
> http://www.x-fetch.com/Component_WhitePapers_PDF/X-Fetch_Performer22_Benchmark.pdf
>
>
> Best regards
> Jouko Salonen
> www.reublica.fi
>
>
>
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]