Sdurham Comments regarding MessageTypes

[Shane.Durham@lexisnexis.com]

Title: Sdurham Comments regarding MessageTypes

These comments refer to the document entitled:
LegalXML System Blue Specification, Working Draft 01, April 25, 2005

General Comments:

We need a description of the MessageType which expresses 'your message has been received'.

In the use cases, I believe we refer to this thing as a 'MessageReceipt'.  For transactional processes, , the 'MessageReceipt' explicitly acknowledges that the sender's data has been received and will be processed by the receiver.

Explicitly identifying the 'action' and 'argument' of each MessageType:

It could be said that the 'blue' message types are a combination of a requested 'action' and 'argument(s)'.
For example: 'Review Filing' represents a requested action of 'Review' and an argument of 'Filing'.

1) The document should explicitly define the 'action' being expressed by each MessageType.

For example: In the section regarding 'Review Filing', something should explicitly describe that this message expresses a requested action  of 'Review', distinct from the argument, 'filing'.  This information will eventually correspond (more or less) to function names in each of our implementation profiles.

2) Likewise, I think the document should better identify the primary 'argument(s)' being expressed by each MessageType.

For example: In the section regarding 'Review Filing', the document does not give the reader the sense of how all of the described data can be collectively thought of as a 'filing'.  The document describes a series of 'blue' data elements, but does not show that they are members of a larger 'filing' data structure, which is, itself, thought of as an argument of the overall 'ReviewFiling' messageType.

I'll try to illustrate the distinction this way:

The current document kinda looks like this:

ReviewFiling
        - property1
        - property2
        - property3
        - property4...

I would advocate an approach more like this:

ReviewFiling ( filing )
        action: ReviewFiling
                - actionProperty1
                - actionProperty2
                - actionProperty3...

        argument1: filing
                - filingProperty1
                - filingProperty2
                - filingProperty3...

89: What do we mean by Receiver here?
Do we mean a particular user?  If so, that value is not appropriate in the context of a 'review filing' message.
The Filing Assembly process will not often (if ever) know the userid to whom a filing is being transmitted.

100-103: I do not understand what is meant here.
I do not believe that the court collects monies from the FilingAssembly MDE (at least, not via a 'blue' defined interaction).  That's the point of PaymentInformation: to express an instrument where 'n' monies may be collected/verified via mechanisms external to 'blue'.

143: It might be helpful if, at this point, the reader were gently reminded that by 'docketing' we do not mean a singular 'docket entry' destined for a case's register of actions.  By 'docketing', we are referring to a general set of data that is to be recorded into the court record, which may include one or more: case participants, attorneys, register-of-actions entries, calendar events, etc.

177: The docketing should also express:
Any fees to be recorded.

186 & 203: I think it will be necessary to indicate which CaseParticipants are to be added to the case, and which ones are included simply because they are related to some other part of the docketing (for example, an existing CaseParticpant might be included in the docketing if the court is trying to update the relationship of that existing CaseParticipant to a NEW attorney.)

189: The docketing might express multiple events to be recorded.

223: I think we should *try* to find a better name for this message type.
Strawmen (none of which are excellent choices either.. But, I am *trying*..):
        "RecordDocketing_callback ( docketingReceipt )" , 
        "ReceiveDocketingReceipt ( docketingReceipt ) "

223 & 242: I believe the 'Callback' to 'RecordDocketing' and 'ReviewFiling' need to optionally express the data which was added to the court record.

277: Suggest: "A unique identifier for the court to which the query is intended/directed."

277: In my view, every MDE (FilingAssembly, FilingReview, CourtRecord, futureMde) has the *potential* to include query interfaces. 

If we acknowledge that there exists MDEs that are not really part of the court's domain (such as FilingAssembly), and we acknowledge that these MDEs *might* have query interfaces, then we should probably not say that ALL 'blue' queries must express courtId.  Afterall, a query into 'FilingAssembly' might not need to express courtId (depending on what the query is, eh?).

For that reason, and others, I think we might still identify queries in our system that do not have to be restricted by courtId.

For this document, I suggest that we just explicitly list courtId as a member in each of the queries described so far, without including the statement that courtId is *always* present in ALL queries.

284: All QueryResponse Messages..

286: FilingQueryId?
I think we mean 'QueryId', as in , the identifier of the query to which this message is a response.

290: FilingErrors?
Shouldn't this be some kind of QueryError element?

The definition is not very clear to me.

The document sort-of implies that 'no data found' should be an error.
This is not necessarily true. 

I would think that GetCaseList should be able to return an empty-list, without indicating an error.

A query error should be generated when:
* The query arguments are considered to be invalid by the receiver, and the query cannot be processed.
* The query represents a request for a specific data item, which cannot be retrieved. (another flavor of 'invalid argument')

* The receiving system explicitly fails while processing the query. (kerplooie)

293: Doesn't this belong in a 'GetPolicy' query, rather than in this general QueryResponse section

305: Suggestions:
Should return a 'filing' data structure, including the state of the filing.

The filing would be absent of any data that is irrelevant to the query.
The filing would be absent of any data that is considered to be inaccessible to the requestor.

(I don't have my GJXDM schema handy...)
If in GJXDM, the state of a filing is not a property of the filing data structure, well, we should probably fix that.

306: I am still unconvinced that we need this query distinct from the 'GetFiling' query.

323: Suggestion:
Should return a 'filingSummary' structure consisting of:
'courtid, filingId, state, received timestamp, CaseId (or 'new'), whatelse?..."

340: Suggestion:
Should return a list of 'filingSummary' structures (as noted above. See 323).

350: This is intended to allow a requester to 'GetCase', with or without parties, with or without the register of actions, etc.

It is intended to be a very flexible approach to getting portions of a case.
However, for the implementer of the query, I think this approach will be generally difficult and inefficient to use.

It would be very difficult to look at an xpath statement and determine which database tables and records must be accessed, and, more importantly, which ones can be ignored, such that I am getting only the data necessary to satisfy the xpath statement.

Because xpath syntax is quite flexible, it would be tricky to parse the xpath syntax, and decide whether or not I need to retrieve (i.e. compose SQL) for ALL data from the register of actions.  Likewise for caseparticipants and calendarEvents. 

As an implementer of this xpath approach, I think I would have to FULLY assemble an XML message, consisting of ALL case entities (dozens/hundreds of parties, dozens-thousands of register of action entries, etc.), and then apply the xpath to eliminate the un-requested values. 

While this is possible, my concern is that it is not a very efficient approach. 
And, the whole point of the sub-case arguments, is to make the query faster (by eliminating unnecessary data).

I think this query needs some more strongly defined arguments for the most common restrictions of the most expensive data from the case-folder.

Strawman:
I propose adding these arguments:

PartySelectionCriteria
- can indicate when NO caseParticipants are to be included in the caseFolder
(note: the output might still include caseParties, if the implementer believes it is necessary to express the parties due to their relationship to other case data.  For example, to fully express a docket entry, it might be necessary for the case to include a caseParty representing the 'filer' of the docket entry, even if the query arguments did not ask for ANY parties to be included).

-?- can indicate a range of caseParticipants to be retrieved by date (date added to the court record)
-?- can indicate a range of caseParticipants by relationship to case (defendant, plaintiff, etc)
-?- combinations of the above.

RegisterOfActionsSelectionCriteria
- can indicate when NO data from the register is to be included in the caseFolder
-?- can indicate a range of RoA to be retrieved by date (date added to the court record)
-?- can indicate a range of RoA by type (motion,judgement, etc...)
-?- combinations of the above.

CaseCalendarSelectionCriteria
- can indicate when NO data from the calendar is to be included in the caseFolder
-?- can indicate a range of calendar events to be retrieved by date (date scheduled)
-?- can indicate a range of calendar events by type (hearingX, hearingY, etc...)
-?- can indicate a range of calendar events by location
-?- combinations of the above.

353: I don't have my GJXDM schema handy to offer decent suggestion here.
Conceptually, it should be a CaseFolder, with or without CasePartyList, with or without RegisterOfActions, with or without CalendarEvents.

CasePartyList contains 0 or more parties
RegisterOfActions contains 0 or more actions (aka docket entries)
(note: A docket entry refers to 0 ore more documents)
CalendarEvents contains 0 or more calendar events

368: Suggestion:
Should return a list of 'caseSummary' elements.
caseTitle, courtId, caseId, caseClassification, caseInitiationDate, caseStatus...

385: Can we somehow better indicate that these arguments are, collectively, a 'filing'?

404: We had discussed at one time that this query could go away, if the CasePArticipant information in the 'GetCase' query were extended to describe ServiceRecipient properties.

421: I had proposed, and I thought we had agreed upon, the concept that each MDE has its own policy.
And so, there is not a 'Court Policy' per se... there is 'FilingReview' policy and 'CourtRecord' policy.
There should even be a 'FilingAssembly' policy, though, it might be very simple at this point (Unlike the other MDEs we have described, FilingAsssembly does not yet have very many interface points.)

539: This section does not yet clearly and explicitly show me how each profile is meeting our requirements.
Or maybe I don't understand what this section's true intention?

I would suggest it would be helpful to the reader if, for each requirement being addressed, the entire requirement be re-stated.

542-547: This material is not very clear to me.
It sort of implies that the initiator of ANY given interaction must be capable of receiving the response to that interaction in both synch AND asynch fashion, depending on the mood of the recipient.

For example, it might imply that the caller must be willing to receive queryResponses in either a synchronous OR asynchronous fashion.

I hope that is not what we meant by this material.
Our interaction models MUST be consistent and predictable. 
I send 'x', they reply with 'Y'.  Everytime, Everywhere.

Perhaps, instead of indicating the profiles need to support 'Asynchronicity of Messaging', it would be clearer for us to indicate that the profile must support these three specific interaction models we have identified.

DataAccess model - simple queryRequest/queryResponse mechanism.
DataUpdate model - transactinRequest/messageReceipt & transactionResponse/messageReceipt.
EventNotification model - eventMessage/messageReceipt mechanics.

566 - 569: It does not seem appropriate to list specific types of documents here.
Are these specific document types in our requirements?  Seems too specific to me.

- Shane Durham
LexisNexis