legalxml-courtfiling message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Conditionals in message structure specifications
- From: "Scott Came" <scott@justiceintegration.com>
- To: legalxml-courtfiling@lists.oasis-open.org
- Date: Mon, 30 May 2005 14:45:43 -0700 (PDT)
In the current specification strawman, a number of conditionals exist in the definitions of message structures.
For example, at line 107, the strawman states, "If the filing is into an existing case, the Review Filing
message MUST include: (list of elements follows)".
Later this week, our domain modeling session will
attempt to formalize the structure of these messages. We will do so by representing the structures in UML static
structure (class) diagrams. These diagrams do not naturally allow for expression of these kinds of conditional
statements.
There are two approaches we could take. I'd like to know which is preferred by the TC.
1. We could include all possible information in the model of the message structure. Then, the model is
supplemented by prose text that describes the conditional rules.
2. We could actually separate the message
structure into several, corresponding to the conditionals. For instance, the structure for a filing into an existing
case would be called something like "Review Filing Message, Existing Case". It would reuse the structure
(probably via inheritance) from the basic Review Filing message, and would add the additional content.
#1
is closest to the current expression in the strawman.
#2 will allow our message structures to be a little
cleaner and easier to consume by implementers (in my opinion.) Also, for the web services messaging profile, we will
wind up with WSDL documents that more cleanly define the MDE interfaces. We will represent the business rules to a
certain extent in the interfaces themselves, which reduces the risk of incompatible implementations of the
over-arching "umbrella" service. This would in turn improve interoperability. However, #2 results in a
more precise but also more complex MDE interface.
I think #1 and #2 are a wash in terms of spec authoring
effort and time.
Thanks.
--Scott
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]