[legalxml-courtfiling-cms-api] RE: [legalxml-courtfiling] Query AndResponse Work-In-Progress

["Durham, Shane (LNG-CL)" <Shane.Durham@lexisnexis.com>]

Title: QnR/CMS API Subcommittee Meeting Oct. 2 - Please respond

Dallas,

 

Very interesting comments.  Thank you so much for taking the time to digest my DTD suggestion and offering your feedback.

 

As to whether there are technical issues with my suggested approach.. I can say that I have succesfully used that 'import' technique under projects involving Microsoft XML Parsers, and SUN XML parsers.  And.. my XML editors, XML SPY and Turbo XML are both compatible with that technique.  It is my impression that it is a very common approach to this type of problem; it is often cited in XML reference books.  

 

The counter examples that you cite, seem to have more to do with an XML document's reference to a DTD, rather than a DTD's reference to another DTD.  For all practical purposes, the technique I describe actually imports one DTD into the other so that from a parser's point of view, it looks like one big DTD (albeit, the parser must be the one to execute the import process.)

 

And, of course, even if LegalXML defined our specs as seperate DTDs, a developer, with a specific parsing issue, could always create a combined DTD for their own projects.

 

 

 

I don't know if anyone said CourtFiling and QueryAndResponse have to be seperate DTDs.  You have correctly identified my assumption.  Maybe someone else can address this question?

 

Perhaps it doesn't matter all that much: essentially, the 'import' technique I support, causes the QueryAndResponse DTD to the be the master combination of the two.  It would be easy enough to twist it around so that CourtFiling is the 'master', so to speak.

 

Actually, I could see a lot more segregation applied to our DTD files so that most of the data elements are in a 'LegalXML dictionary DTD and much of CourtFiling and QueryResponse become rather small function descriptions that reference and implement items from the dictionary.   There perhaps would exist a master DTD that would bring all of the others together as a convenience.  I think this is essentially the direction we are heading in LegalXML II.

 

 

Of Filing Response:

I concur with the idea that a filing, itself, could generate a 'response' of some sort.

 

I'm not sure what I think about 'filing' generating a 'response', and then later also creating a 'confirmation'.

That quality of having 'multiple results' for a single request is a smidge unsettling to me.

 

The current CourtFiling specification allows multiple 'confirmations' to occur for a single filing... and while I understand the purpose and intent of the design, there is an uncomfortable adhoc-ish quality to it all.  I think I'd like to see a distinction from 'confirmations' which are, more or less, for messaging and those that are a result of processing.  And, I would probably like to see a single response to any given processing request.

 

Let me put it another way:

I tend to want to describe API as Query/Response, Function/Result models.   or as  "DoThis - DidThat".

 

Our current filing specification has this kind of quality:

DoThis - DidThat... and DidThatToo... and DidSomeMore... and MaybeImDoneNow.... and MaybeImNotDone...  and StillDoingStuff...

 

I don't concur that including QueryAndResponse directly in the CourtFiling DTD is a satisfactory solution to the underlying issue: the limitation of what can be expressed via 'confirmation'.  However, I don't see that your suggestion is hurtful or inconsistent with our present LegalXML 1.x goals.

 

So.. .I am not opposed to your suggestion.  CourtFiling DTD can include QueryAndResponse DTD (rather than the other way around).

 

I still think... it might be best to tackle this via the 'import' approach I have described.. but... that too is not a truly sticky point for me either.

 

I look forward to additional feedback from you and others,

- Shane

 

 

 

-----Original Message-----
From: Dallas Powell [mailto:dpowell@tybera.com]
Sent: Tuesday, October 08, 2002 3:14 PM
To: legalxml-courtfiling-cms-api@lists.oasis-open.org
Cc: legalxml-courtfiling@lists.oasis-open.org
Subject: Re: [legalxml-courtfiling] Query And Response Work-In-Progress

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