legalxml-courtfiling — archive

[Christopher Durham]

 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: "Durham, Shane (LNG-CL)" <Shane.Durham@lexisnexis.com>
To: 'Dallas Powell' <dpowell@tybera.com>
Date: Tue, 08 Oct 2002 16:20:49 -0700






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