OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-courtfiling message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]