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" <dpowell@tybera.com>
- To: <legalxml-courtfiling@lists.oasis-open.org>
- 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
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]