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

["Chambers, Rolly" <rlchambers@smithcurrie.com>]

Shane,
 
I think your suggestion to use the "import" technique is a good one. It
looks like a way to permit more orderly segregation and development of
Legal XML DTDs. 
 
It reminds me some of the approach apparently taken by the Schools
Interoperability Framework (SIF)( http://www.sifinfo.org/about.html).
SIF is tackling the problem of interoperability in the context of
instructional and administrative software applications for schools.
 
I don't have strong preferences one way or the other regarding the
specific points being discussed. I agree with you on most of them,
although I somewhat favor making 'Court Filing' the "master" DTD instead
of 'Query and Response.' I also agree the technique works either way.
 
Rolly Chambers

	-----Original Message----- 
	From: Durham, Shane (LNG-CL) 
	Sent: Tue 10/8/2002 7:20 PM 
	To: 'Dallas Powell' 
	Cc: legalxml-courtfiling@lists.oasis-open.org;
legalxml-courtfiling-cms-api@lists.oasis-open.org 
	Subject: [legalxml-courtfiling-cms-api] RE:
[legalxml-courtfiling] Query AndResponse Work-In-Progress
	
	
	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

<<winmail.dat>>