RE: [legalxml-courtfiling] Common data elements across messages

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] Common data elements across messages




From: 
To: 
Date: Wed, 1 Jun 2005 09:15:55 -0700 









>> Might it not be a useful 
thing (or at least potentially useful) for all Blue message structures to 
contain these pieces of information?
>> Should we 
include the sending (and perhaps the receiving) MDE ID on all messages as 
well?
 
FilingId:

  I think that making FilingId a 
  member of every non-query message would be a bit 
  short-sighted.
   
  Though I am *usually* a stickler for 
  working within our explicit requirements, the practical side of me must 
  speak out from time-to-time as well...
   
  It is not difficult to foresee many 
  interactions between MDEs that will not refer to a filing, and therefore not 
  have a filingId.
   
  1) Query interactions are an 
  immediate example from our current requirements.
  Not every query needs 
  to refer to a filingId.
   
  2) The 'docketing process' 
  might also be without filingId, if (as I have suggested) we were to consider a 
  docketing as a stand-alone concept.  Just 
  consider a scenario when we might want to record data that did not 
  originate from an electronic filing process.
   
  3) Going just a little bit 
  outside of our current requirements, a 
  'filer registration' process would likely be without 
  filingid.
  I have been involved in 
  at least two systems that explicitly implemented a registration 
  process.  It is a very real process we will eventually need to 
  develop.
   
  I suggest that we 
  indicate filingId as an explicit member of those messages that are filing 
  related. We should *not* attempt to make it a member of *all* blue 
  non-query messages.
 
MdeId, SubmitterId, ReceiverId, 
SubmissionDateTime:
 
I think that every interaction between 
MDEs should express:
(note - I am not stuck on the terms I 
have used.  They are just strawmen.)
 

- 'MessageSystemId' - The 
system from which the message was generated


  I 
  *might* be willing to say this is more-or-less the same thing as 'The MDE from 
  which the message was generated' and *might* be just as easily called 
  'FromMde'.  
   
  However, not every message that is assembled and transmitted will come 
  from what-we-would-consider to be an MDE.  Queries continue to be a 
  decent example of this - a valid query message can be assembled and 
  transmitted *to* an MDE, though the caller, itself, might not be able to 
  receive any blue messages and is not, itself, an 
  MDE.
   
  Consider a stand-alone kiosk that is designed to interact with a 
  CourtRecord MDE's query functions.  The kiosk, itself, is not really an 
  MDE.  It just interacts with an MDE.  Nevertheless, something in our 
  blue messages should permit the kiosk to express its identity in some way 
  that permits the CourtRecord MDE to authenticate the kiosk (to the 
  satisfaction of the implementers).
   

- 'MessageTimestamp' - The 
timestamp of when the message was assembled and transmission 
initiated.

  I 
  think we should use a different term for this value than 
  SubmissionDateTime.
   
  Lots 
  of folks prefer think of 'SubmissionDateTime' as 'the legal time a filing 
  is considered as transmitted to the court'.
   
  In 
  this context, I think we mean something quite a bit less weighty (and, 
  perhaps, less open to interpretation). 
   
  For 
  each blue message, we would like a timestamp representing when the 
  message was assembled and its transmission initiated. 
  
   
  Note 
  that this the timestamp value does not (could not) indicate that the 
  message was received, nor does it necessarily have any legal meaning (as 
  'submissionDateTime' might).  It is merely a courtesy/systemAdmin value 
  that *could* be given more functional meaning, if the implementation wants to 
  do so.
   
  I 
  suggest we just call it 'MessageDateTime'.
   
  Note1: Some developers might fuss about my definition of 
  'MessageDateTime'.  They *might* nit-pick that the timestamp of when a 
  message was assembled and when a message was transmitted could be very 
  distinct values, and, the distinction could be important to some 
  implementers.  I think a single timestamp is generally sufficient for our 
  purposes but I could be easily coaxed into adjusting our standard such 
  that it supports TWO timestamps, messageSentTime and messageAssembledTime, 
  where 'assembledTime' would be an optional 
  value.
   
  
  Note2: Functionally, we of course need a timestamp to indicate when a 
  message was received.  For DataUpdate interactions, (and 
  EventNotification and Report interactions) , this functional 
  value would be the 'MessageTimestamp' expressed within the 
  'MessageReceipt' message.   For Queries, the received timestamp is 
  essentially the 'MessageTimestamp' expressed in the query response (or 
  QueryFault).  Or, I suppose all of these response variations could 
  contain an element to explicitly indicate when the initiating message was 
  received.
   
- 'MessageUser' - The user functionally responsible 
for initiating the interaction (even if null / 
public)


  Of course, we haven't yet defined 
  any practical pattern for how users could be expressed such that 
  they are consistently meaningful between a system's MDEs.  But, in 
  theory, this message property exists and should be expressible.  We need 
  to work on it.
- 'ToMde' - The MDE to which the message is 
intended

  This would seemingly be a 'courtesy' 
  value.  
   
  The MDEs will often (if not always) 
  have distinct addresses in the overall system such that that a message is 
  directed to a specific MDE at a specific address, and any information 
  embedded within the message, to indicate the intended 'to Mde' is 
  somewhat redundant.
   
  But, when you start to talk about 
  issues of security, message validation, authentication, etc.  we can get 
  some good warm fuzzies to clearly see that a message received by my 'xx MDE' 
  was, indeed, explicitly intended for my 'xx MDE'.  
  
   
- 'ReplyToMde' - 
The MDE to which a response, if any, is to be 
directed.

  DataUpdate (i.e. Transactional) interactions, can make the most use of 
  this value in order to identify the MDE to which a callback function should be 
  directed.    Likewise for 'Report Interactions', if/when we 
  decide to implement such processes.

  Query interactions (and 
  EventNotification interactions) would not absolutely need this value, since 
  their responses are synchronous - directly and immediately 
  returned to the caller.  However, even in a query scenario, the 
  'reply to MDE' might be useful for system adminstrators' authentication logic 
  or in the event of an unusual interaction failure.
   
- Shane Durham
LexisNexis
 



From: Cabral, James E. 
[mailto:]
Sent: Tuesday, May 31, 2005 8:52 
PM
To: ; 

Subject: RE: 
[legalxml-courtfiling] Common data elements across messages



Scott,
 
1. I agree that these elements should be common to filing 
messages.  However,  I'm not sure we need these for 
queries.
 
2. While the Submitter 
and Receiver ID should be in the Court Filing XML, I believe the MDE IDs 
probably should be in all messages - does this necessarily make it 
nonfunctional?.  However, I think the MDE ID should also be independent of 
the messaging profile.

3. If 
we do put the MDE IDs in the messaging profile, what does this mean for 
assigning MDE IDs?
 
  
jim
 


From: Scott Came 
[mailto:]
Sent: Monday, May 30, 2005 2:05 
PM
To: 
Subject: 
[legalxml-courtfiling] Common data elements across messages


In preparing the domain models for this week's modeling session, I've 
noticed that there are four data elements that are common to all of the message 
structures in the current specification, except for the query and response 
messages (using those terms loosely.)  The common elements in the other 
message structures are:

Filing ID
Submission Date/Time
Submitter 
ID
Receiver ID

Also, the Review Filing message contains the sending 
MDE ID.

Several questions:

1.  Might it not be a useful thing 
(or at least potentially useful) for all Blue message structures to contain 
these pieces of information?  That is, can we include them in the 
structures of the query and response messages as well?  (If this were 
thought to be a good idea, we'd likely want to change "Filing ID" to something 
like "Message ID".)

2.  Should we include the sending (and perhaps 
the receiving) MDE ID on all messages as well?

3.  If we decided to 
include these on all messages, an argument could be made that they are really 
non-functional in nature, and therefore should be implemented by the messaging 
profiles rather than in the main Blue message body.  The point to consider 
here is that many messaging infrastructure platforms already contain mechanisms 
for populating and sending these elements.  The platforms generally provide 
easy developer/integrator access to the information at the receiving end.  
If we push the population of these elements into the non-functional 
requirements, then implementers will be allowed to take advantage of facilities 
that already exist.

For the web services messaging profile, everything 
but submission date/time is included in WS-Addressing.  Other profiles 
would of course have their own mechanisms for implementing 
them.
--------------------------------------------------------------------- 
To unsubscribe from this mail list, you must leave the OASIS TC that generates 
this mail. You may a link to this group and all your TCs in OASIS at: 
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 













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

--

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