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

[John Messing <jmessing@law-on-line.com>]

I think Shane's approach and Rolly's comments may well be appropriate in the
context of unsigned responses, but I think unsigned responses should be
discouraged if not outlawed  where XML is concerned. If digital signatures
are involved, as I believe they should be as a matter of course, then
incorporations by reference or imports may cause complications that throw
the signatures off and result in verification issues. That is the reverse
side of the coin.

----- Original Message -----
From: "Chambers, Rolly" <rlchambers@smithcurrie.com>
To: <legalxml-courtfiling@lists.oasis-open.org>
Cc: <legalxml-courtfiling-cms-api@lists.oasis-open.org>
Sent: Tuesday, October 08, 2002 7:09 PM
Subject: RE: [legalxml-courtfiling-cms-api] RE: [legalxml-courtfiling] Query
AndResponse Work-In-Progress


> 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
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>