legalxml-courtfiling — archive

RE: [legalxml-courtfiling] Comment period for existing artifacts

From: Christopher Durham
To: [email protected]
Date: Mon, 01 Aug 2005 16:59:00 -0000

MHonArc v2.5.0b2 -->

legalxml-courtfiling message

Subject: RE: [legalxml-courtfiling] Comment period for existing artifacts

From: [email protected]
To: [email protected]
Date: Mon, 1 Aug 2005 10:03:54 -0700

I apologize for being miserably late with these comments.

Policy and Policy MDE:

In the current work-product, there exists a single CourtPolicy and PolicyMDE for the system.

I do not believe this is what we want.

It implies the older LegalXML policy model (and other standards have adopted this as well), where there exists a single 'policy' for the system describing how ALL components are to interact.

A single policy for the entire system, will become a large convoluted beast.

It will be difficult to develop, maintain, manage, and consume.

Instead, we want to adopt a model where each MDE has its own policy to describe how *that* MDE behaves.

We need to think in terms of 'FilingReview-Policy', 'FilingAssembly-Policy', 'CourtRecord-Policy, etc

Query MDE:

In the current work-product, there exists a single query MDE for the system.

I do not believe this is what we want.

Just as each MDE has the potential to support one or more transactional processes, each MDE also has the potential to include query interfaces.

So, there would not be a singular 'QueryMDE' for the system....

Instead:

A 'FilingReviewMDE' should/can include query interfaces related to 'FilingReview' data.

Examples: 'GetFilingStatus', 'GetFiling', 'GetDocument', 'GetPolicy'

A 'CourtRecordMDE' should/can include query interfaces related to 'CourtRecord' data.

Examples: 'GetCase', 'GetDocument', 'GetPolicy'

A 'FilingAssemblyMDE' should/can include query interfaces related to 'FilingAssembly' data.

Examples: 'GetPolicy', 'Get??

A 'ServiceMDE' should/can includes query interfaces related to 'Service' data.

Examples: 'GetPolicy'

Base message as SOAP Message:

I think that ALL of our XML messages should be in SOAP format.

I feel pretty strongly about this too.

I know that, many of you will quickie shake your heads 'No Way', though I am not entirely sure why.

One argument is that a SOAP message format would restrict us to a particular implementation profile.

That is not true.

We must remember that SOAP messages, are merely an XML format for expressing function-and-argument.

(i.e. Remote Procedure Calls) At heart, it is an XML message, that includes 'action', and 'arguments', as well as being able to express 'caller' and 'recipient', and all other sorts of useful data.

By function-and-argument, I mean things like: 'GetCase ( myGjxdmCaseId )' and 'ReviewFiling ( myGjxdmFiling )'

SOAP messages are XML. And, just like any other XML message, SOAP messages can be exchanged between components, in any profile we like.

COM, CORBA, WebServices, eBXML, and, yes, sneaker net.

We need to understand: You don't have to implement WebServices to assemble OR parse SOAP messages.

As with any XML message format, you can read and write SOAP messages, using standard XML tools.

It is no more difficult than reading/writing the non-SOAP messages we are currently proposing to invent.

I think it would be quite silly and short-sighted of us to NOT use the well-defined SOAP format as our base for expressing function-and-args.

We will not be anywhere near as successful if we attempt to invent our OWN format for that purpose.

These UML-ish statements might help illustrate what I am advocating:

Instead of this:

GjxdmMessage{ GetCase ( myGjxdmCaseId ) }

We have this:

SoapMessage{ GetCase ( myGjxdmCaseId ) }

In COM, instead of this:

COM-->Send( GjxdmMessage )

We have this:

COM-->Send( SoapMessage )

In HTTP, instead of this:

Http.Send( GjxdmMessage )

We have this:

Http.Send( SoapMessage )

NOTE: The HTTP example, when implemented with WebServices/ebXM toolkits, can be simply thought of as:

WebService-GetCase( myGjxdmCaseId )

...only because WebService toolkits nicely hide the 'HTTP.Send' part of the process.

No biggy.

In the end, exchanging SOAP messages is the same as exchanging XML.

SOAP *is* XML.

- Shane Durham

LexisNexis

From: John M. Greacen [mailto:[email protected]]
Sent: Tuesday, July 19, 2005 11:08 AM
To: Electronic Court Filing Technical Committeee
Subject: [legalxml-courtfiling] Comment period for existing artifacts

has posted on KAVI the domain models, definitions, and GJXDM mapping spreadsheets for all of the ECF 3.0 messages. On the conference call that just concluded we agreed to vet those documents on the following timeframe:

Comments and suggested changes from TC members by no later than the close of business on Wednesday, July 27^th.

Review of the comments by the subcommittee of Cabral, Came, Clarke, Greacen and Tingom by Sunday, July 31^st.

Resolution of outstanding issues identified by the subcommittee on a conference call at our regular Tuesday time, August 2^nd.

I have scheduled a conference call for that purpose as follows:

Date Tuesday, August 2, 2005

Time 1:00 pm Eastern time; 10:00 am Pacific time

Call in number 1-605-528-8855

Access code 2892164

We also decided on the following additional steps:

will continue to moderate the eService discussion until it is resolved.

A subcommittee of Bergeron, Came, Cusick, and Leff will develop the requirements for an ECF 3.0 profile, using the WS I profile as a means of identifying all such requirements. This process will necessarily also refine the non-functional requirements.

Complete minutes will follow in due course.

John M. Greacen

Greacen Associates, LLC

HCR

505-289-2164

505-289-2163 (fax)

505-780-1450 (cell)

[email protected]

Follow-Ups:
- Re: [legalxml-courtfiling] Comment period for existing artifacts
  - From: "Dallas Powell" <[email protected]>