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

[Shane.Durham@lexisnexis.com]

On this matter,  I don't think we can say 'yes, always do it this way'... or 'that way'.

 

I can only hope that we might occasionally recognize when two-or-more major variations of 'Thing' should be represented with object inheritance, such that we have 'ThingVaration1' and 'ThingVariation2'.

 

In the example Scott mentioned, I do not see 'existing CourtCase filing', and 'new CourtCase filing' as two sub-classes of 'filing'. 

 

However, I *might* see 'existing CourtCase' and 'new CourtCase' as two sub-classes of 'CourtCase', where certain properties are required/optional in the different sub-classes.

 

Likewise, I *might* see 'civil filing' and 'criminal filing' as two sub-classes of 'filing', because, I think, they would have significantly different sets of properties that might be cumbersome to express merely as 'optional' members of filing.

 

I think there is a time-and-place for inheritance techniques.

We should not entirely dismiss them, nor should we overuse them.

(..not very profound I suppose.)

 

- Shane Durham

LexisNexis

 

 

---

From: Scott Came [mailto:scott@justiceintegration.com]
Sent: Wednesday, June 01, 2005 7:25 AM
To: legalxml-courtfiling@lists.oasis-open.org
Subject: RE: [legalxml-courtfiling] Conditionals in message structure specifications

Well, I'd say the complexity you mention really exists (it's not 
introduced by this approach), so it has to be dealt with in some way.  
However, in the interest of getting the spec done by mid-July, I can see taking 
the approach of just presenting the rules in prose.  Something we might 
want to look at down the road.

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