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

["Cabral, James E." <JCabral@mtgmc.com>]

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:scott@justiceintegration.com]
Sent: Monday, May 30, 2005 2:05 PM
To: legalxml-courtfiling@lists.oasis-open.org
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