MHonArc v2.5.2 -->
legalxml-courtfiling message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [legalxml-courtfiling] Query And Response Work-In-Progress
From: Dallas Powell <>
To:
Date: Tue, 08 Oct 2002 16:13:41 -0600
Title: QnR/CMS API Subcommittee Meeting Oct. 2 - Please respond
There are a couple of items that your request
exposes to me as issues we would like to present.
First:
Splitting a DTD and referencing a separate
DTD through external parameter entities could be less reliable. Also
according to XML HandBook - Third Edition 50.5.1 "XML processors are allowed, but not required, to
validate an XML document when they parse it. The XML specification allows
a processor that is not validating a document to completely ignore declarations
of external parsed entities ( both parameter and general)."
My only concern is that it may cause difficulties for some products. I
know that in the Georgia Interoperability test, validating documents vs. parsing
for syntax was an issue for some vendors. Some document instances
were including references to a DTD that were local to some
other system that we did not have access to, so when we loaded the
document instance for parsing we had to write a kludge which dealt with DTDs
that we could not find.
Second thought:
"To avoid
explicitly re-defining all of the CourtFiling elements into the QueryResponse
DTD" suggests that it has already been agreed to separate
Filing & Confirmation from Query & Response into two DTDs
because they do not belong together. I don't know if the TC has
already agreed to this or not? However, our experience says that we need
more than confirmation associated with a filing. First let me refer
to Catherine Krause's status report attached to this message. She points
out that the confirmation elements do not provide adequate definitions to
include all the information they wanted to include when responding to a
filing. Bullet item 4 & 5 under lessons learned indicate
they needed a place where they could include error messages and "We had wanted to include the documentTitle in the filing
receipt because the received message would be less than helpful
when it references a Filename or Path name only."
Our experience was even more difficult because Utah
allows case initiation and automatic collection of fees through
credit cards. We needed significantly more data included in our response
to a filing. Our response is asynchronous and provides for several
confirmation responses to a single filing. In addition to our confirmation
responses, we found it necessary to include a document that included
documentTitle, authorization codes for master card, amounts charged, Judge
assigned to the case, error messages and so forth.
We realize that the definition of a Response for
LegalXML only describes it in relationship to a Query, but for us, we would
propose the idea that a LegalXML Response document may be returned due to a
filing and not just a Query or else the confirmation allow the inclusion of
documents.
Dallas
