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: "Cabral, James E." <>
To: <>,<>
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:]
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]
