RE: [legalxml-courtfiling] Conditionals in message structure specifications

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

Scott,

 

I understand your concern with our current approach.  However, I think the second approach introduces too much complexity, particularly with combinations of conditions.  For instance, what if we have multiple intersecting conditions, each with their own conditional elements - such as 1. a new case and 2. a criminal case.  Using the second approach, this results in a geometric increase in the number of separate use cases (e.g. Review Filing - New Case - Criminal Case).  I prefer our current approach, although it is simplistic.

 

  jim

---

From: Scott Came [mailto:scott@justiceintegration.com]
Sent: Monday, May 30, 2005 2:46 PM
To: legalxml-courtfiling@lists.oasis-open.org
Subject: [legalxml-courtfiling] Conditionals in message structure specifications

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
--------------------------------------------------------------------- 
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