Re: [legalxml-courtfiling] Apologies and follow-up to Jan 6th 2004 conference call

["Dallas Powell" <dpowell@tybera.com>]

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 vijay@adviceAmerica.com: "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?

 

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?

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
> 
> 
> 
> 
> -----Original Message-----
> From: Duane 
Nickull [mailto:dnickull@adobe.com]
> Sent: 5. tammikuuta 2004 
21:00
> To: John.Borras@e-Envoy.gsi.gov.uk
> Cc: egov@lists.oasis-open.org; 
mwhughes@sandproof.org
> 
Subject: Re: [egov] Re: Need advice regarding XML performance issues
> 
> 
> Michael:
> 
> Performance is a very loaded 
term.  We have had huge debates on this 
> going back to 1996 
on  the XML-dev list.  I will try to recall some of 
> the 
points we agreed on.
> 
> 1. Performance is affected largely by 
platform, programming language and 
> physical memory (*both heap and 
stack)
> 2. Sax is an Event based model.  I have a PPT slide that 
explains the 
> concept of SAX very clearly at
> http://www.nickull.net/presentations.html. (download the one entitled 
> Washington - Day Three).  Sax 
works by reading in an XML document as a 
> one dimensional stream of 
bytes.  When an enough bytes are read that an 
> "event" is 
recognized, an event notice is dispatched up the stack.  The 
> event 
notices are simple text messages that look something like this
> 
> 
StartElement=["foo"];
> 
> The above event is the parsers way of 
telling the parent that 
> instantiated it that is has encountered a start 
element named "foo". 
>  Once the event has been dispatched.  No 
residual memory of the event is 
> kept.  This makes SAX a preferable 
methodology for parsing when there 
> are strict memory 
requirement.
> 
> Since XML does not contain any semantics, a parser 
is simply a reader. 
>  Nothing is done with the XML except reading 
it, checking it for errors 
> and resolving entities (three mandatory 
items) and a fourth optional 
> item of validating it against a DTD or XMl 
Schema.  The latter also 
> slows down parsing.
> 
 
> The Java SAX implementation (Xerces), accordingly has four main 
handlers 
> (entity resolver, error handler, Validation handler and event 
handler. 
>  It is up to the programmer to capture all the events 
that get passed up 
> and do something meaningful with them. *** This is 
the place where a lot 
> of performance can be gained or lost!!!  
Since just about all programs 
> that consume XML documents will 
eventually do something with them, the 
> skill of the programmer writing 
the handler code greatly affects things 
> like memory, speed etc.  
If you use a language like Java with automatic 
> garbage collection, your 
memory options are managed for you however you 
> can still tune it 
further.  If you work in a language like C or C++ 
> (ANSI), the 
skill of the programmer is going to affect your systems 
> 
performance.
> 
> 3. If one requires to keep a model of the XML 
document and run a series 
> of programmatic tests against it, you will 
likely use the DOM.  DOM 
> (Document Object Model) works by 
accepting the events from the SAX 
> handler (* although use of sax is not 
mandatory) and building an in 
> memory representation of the original XML 
document.  Tests and queries 
> can then be run against the DOM tree 
to test for certain conditions, 
> etc.  Performance is greatly 
affected here by what kinds of tests you 
> will run against your XML 
tree.  This is a point of contention for those 
> who advocate XML 
automatically written out from a model since not all 
> object models will 
result in XML that is efficient to query.  IMHO - a 
> balance has to 
be struck between the modellers requirements and the 
> programmers/system 
administrators.  Anyways, XML like this:
> 
> 
<root>
>   <tag one/>
>   <tag 
two/>
>   <tag three/>
> </root>
> 
> will be easier on processor speed that this:
> 
> 
<root>
>   <tag one>
>      
<tag two>
>         <tag 
three/>
>      </tag two>
> 
     <tag two>
> 
         <tag three/>
> 
     ...
> 
> if you are iterating through a 
deep tree looking for matches.
> 
> Summary:
> 
> I have 
studied the performance issues for a lot of years and will attest 
> that 
it is an extremely complex issue and the truths about it change 
> almost 
monthly as parsers are upgraded, new chipsets come out, new API's 
> to 
the O/S are used, newer versions of garbage collection (Java, C#) are 
> 
invented etc.  To be up to date is almost impossible however there are a 
> simple set of rules that can probably get you 85% of the way 
there.
> 
> If you are eager to delve into this subject more 
thoroughly, please 
> contact me offline and I can provide you with some 
links etc.
> 
> Cheers
> 
> Duane Nickull
> 
> 
> 
> 
> 
> John.Borras@e-Envoy.gsi.gov.uk 
wrote:
> 
> >
> > TC Members
> >
> > 
Can anyone provide any pointers or advice to Michael please?  
> 
>
> > If there are any commercial sensitivities about your advice 
then I'll 
> > leave you to negotiate directly with him for providing 
that advice.
> >
> > John
> >
> >
> 
> "Mike Hughes" <mwhughes@sandproof.org>
> >
> > 31/12/2003 21:12
> >
> > 
To
> > <john.borras@e-envoy.gsi.gov.uk>
> > cc
> >
> > Subject
> > Need 
advice regarding XML performance issues
> >
> >
> 
>
> >
> >
> >
> >
> >
> 
> Dear Mr. Borras,
> >  
> > I am researching 
performance issues related to XML and need to speak 
> > with an 
expert.  I understand that you Chairman of the OASIS 
> > 
e-Government Technical Committee..  
> >  
> > I 
would appreciate it if you could reply to this email with the names 
> 
> of people who could provide related input, particular with regard to 
> > specific standards and conditions that affect performance very 
> > adversely.  Also, I need to understand what measures, 
commercial or 
> > standards-related, are being taken to resolve such 
performance problems.
> >  
> > Thank you for any 
assistance you can provide.
> >  
> > Sincerely,
> 
>  
> > Michael W. Hughes
> > Amplicast
> > 
Erie, CO
> > USA
> >
> >
> > PLEASE NOTE: 
THE ABOVE MESSAGE WAS RECEIVED FROM THE INTERNET.
> >
> > On 
entering the GSI, this email was scanned for viruses by the 
> > 
Government Secure Intranet (GSI) virus scanning service supplied 
> > 
exclusively by Cable & Wireless in partnership with MessageLabs.
> 
>
> > GSI users see 
> > http://www.gsi.gov.uk/main/notices/information/gsi-003-2002.pdf for 
> > further details. In case of problems, 
please call your organisational 
> > IT helpdesk.
> >
> 
> -- 
> Senior Standards Strategist
> Adobe Systems, 
Inc.
> http://www.adobe.com
> 
> 
> 
> 
> 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/egov/members/leave_workgroup.php.
> 
> 
> 
>

---

> 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.