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

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] Conditionals in message structure specifications




From: "Cabral, James E." <>
To: <>,<>
Date: Tue, 31 May 2005 20:51:35 -0700










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:]
Sent: Monday, May 30, 2005 2:46 
PM
To: 
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 













[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]