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

MHonArc v2.5.0b2 -->
















legalxml-courtfiling message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








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




From: 
To: 
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:]
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 27th.  
Review of the comments by the 
subcommittee of Cabral, Came, Clarke, Greacen and Tingom by Sunday, July 31st.
Resolution of outstanding issues 
identified by the subcommittee on a conference call at our regular Tuesday time, 
August 2nd.

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)







Follow-Ups:

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








[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]