[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [legalxml-courtfiling-policy] Sdurham - RE: Final Call - Cour tFiling Policy Requirements
I agree that we need to have a consistent architectural approach to Legal XML messaging and that it is lacking now. I'm not sure that is a show stopper for Court Policy. All of its implied API's must be implemented consistently in EFM and EFSP components in real life, but the current spec says almost nothing about how that implementation would occur at the component level. -----Original Message----- From: Durham, Shane (LNG-CL) [mailto:Shane.Durham@lexisnexis.com] Sent: Monday, October 21, 2002 10:24 AM To: 'legalxml-courtfiling@lists.oasis-open.org'; 'legalxml-courtfiling-policy@lists.oasis-open.org' Subject: [legalxml-courtfiling-policy] Sdurham - RE: Final Call - Court Filing Policy Requirements >> Please give a final thoughtful read. I thank you in advance for your input and involvement. << I have attached a word document with my comments. (use ms-word's 'view comments') A prior reviewer's comment's "RLW" are also within the document. Those are not mine. General comments and conclusion: As I stated in Boston, I think LegalXML 1.x is not consistently structured to facilitate an associated Policy structure. This requirements spec, while a respectable and very decent starting point, contains a deep assumption that policies will be specifically developed against CourtFiling 1.x, QnR 1.x, Document 1.x, etc. I would suggest we shouldn't be talking about CourtFiling policies.. or QnR policies.. but, simply, "LegalXML Message" policies. Unfortunately, in LegalXML 1.x, there isn't really a consistent concept of a 'LegalXML Message'. CourtFiling is a bit different than QnR... and is a bit different than Document. As it stands, they would need independent policy structures for each of those API. And, 'policy' can be ferociously complex... let alone having to develop it against three models. The document sufficiently describes the requirements for a LegalXML 1.x policy set. However, it reveals to me, that a reasonably implement-able policy set for LegalXML 1.x is not do-able. I think the work is too complex because the underlying Filing, Document, and QnR specs do not follow a very consistent model (which is simply a sign of an immature API... it naturally happens... no offense to the development's participants, including myself). So... I suppose I conclude: ** I can not approve the spec with respect to its intended use for LegalXML 1.x, on the grounds that such work is not technically feasible and that such work would not be implement-able. Furthermore, I do think that LegalXML 1.x can facilitate the development of any feasible Policy system as currently envisioned by the LegalXML participants. ** (I do not intend for my position to become a filibuster. If I am virtually alone in this opinion, I will withdraw my dissenting 'vote' and allow the consensus to proceed.) With respect to LegalXML 2.x, and the hopes that it has a more 'policy-friendly' approach to its API, a policy requirements spec, at this time, would be a bit premature but it certainly should be considered a serious working draft as LegalXML 2.x takes shape. - Shane Durham LexisNexis CourtLink
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC