[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Apologies and follow-up to Jan 6th 2004 conference call
TC Chair and Members, Sorry i had to ring-off early from yesterday's (1/6) conference call. I was called away from my desk. I realize it was unfortunate i missed the remaining detailed discussion of the Court Filing Blue definition. I look forward to reading the conference call minutes to learn the final "Blue" definition. There are several thoughts i wish to share with TC members as we move forward in 2004 Court Filing discussions and initiatives. <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 work 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)? " * There needs to be clarification between Court Document (court filings types) and the messaging schemas associated with EFM. 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 court filing types? where does this scope of work intersect with Blue vision? 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? Decision for TC members to entertain: Is this type of standard/specification development of value to the legal/justice community? If so, where does it belong: OASIS Legal XML or OASIS e-government, or a different effort similar which could be defined along the lines of the Education TC purpose statement ? The purpose of the OASIS Education XML TC is to represent international pre-Kindergarten through 12th grade (PK12) interests by developing XML requirements documentation for shared extensible user profiles, controlled vocabularies, taxonomies, and thesauri, and other needed specifications. 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 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 OXCI or how OXCI development supports Blue specification creation? 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? 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)? 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]