[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [legalxml-courtfiling] Query And Response 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC