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

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:]
Sent: Tuesday, October 08, 2002 3:14 
  PM
To: 
  
Cc: 
  
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