legalxml-courtfiling — archive

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

From: James Cabral
To: [email protected]
Date: Wed, 01 Jun 2005 03:52:00 -0000

MHonArc v2.5.0b2 -->

legalxml-courtfiling message

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

From: "Cabral, James E." <[email protected]>
To: <[email protected]>,<[email protected]>
Date: Tue, 31 May 2005 20:51:33 -0700

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:[email protected]]
Sent: Monday, May 30, 2005 2:05 PM
To: [email protected]
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