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: "Scott Came" <>
To: 
Date: Wed, 1 Jun 2005 07:24:35 -0700 (PDT)






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