OASIS Open Mailing List Archives  ·  All Lists  ·  legalxml-courtfiling  ·  2002-10

legalxml-courtfiling — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

Re: [legalxml-courtfiling] Query And Response Work-In-Progress


 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


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
 


[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]