courtfiling-reqts message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [courtfiling-reqts] Shane's Comments for Eric
- From: "Scott Came" <scott@justiceintegration.com>
- To: courtfiling-reqts@lists.oasis-open.org
- Date: Thu, 10 Feb 2005 14:43:19 -0800 (PST)
Shane, I am in general agreement. Specifically...
#1...Agree
100%
#2...In general I think this is a good idea. I have a
couple of concerns.
Remember that eventually this is going to
have to be represented in normative language in the spec. So as long as
we can translate or use the UML diagrams in that context, we're fine.
That should be a periodic litmus test, though.
Also, there are
some textual properties in the current use cases that I think we'll want
to maintain somehow in the new diagrammatic world. I think the goal,
minimal guarantee, success guarantee, and interface type are all good
things to have. The interface type could be represented with a
stereotype. I don't know how to do the rest without having some kind of
textual artifact accompanying the diagram. So I guess that's what I
propose...use diagrams, but allow for a text-based artifact associated
with them so that we can communicate things that can't be handled
diagrammatically.
#3...ok
#4...ok
In
general, in terms of the "technical" representation of the
message contents that travel between components... I would like to see us
leverage the exchange document development process work that has proved
useful over on the integrated justice side of LegalXML (and is being
slowly but surely adopted by other groups in the national justice
community.) Eric is very familiar with this process (right Eric?) and it
should help us produce normative content in a way that is readily
accessible to our stakeholders.
In particular, that process
starts with an object modeling exercise that represents (in business
vocabulary) what the message structure should be. Then that structure is
mapped, using well-known techniques, to GJXDM. Finally the mapping is fed
into the standard GJXDM tooling (i.e., the subset schema generator) to
produce schemas.
Thanks for pulling this together.
--Scott
> I have given some feedback to Eric regarding the
approach to the use
> cases,
> and some comments on the
content. I want to summarize my suggestions here
> and get any
feedback you guys care to offer.
>
> Of course, we have
the comments from last Tuesday's conference call to
>
incorporate.
>
> These include:
> - less
component-oriented language
>
> - clarification of
'method of payment' so that it is understood the filing
> review
clerk decides that the filings fees will be, or have been, paid, in
> some manner acceptable to the court.
>
> -
clarification that interactions with the "court record" (or
any
> component)
> might occur during the Filing Assembly
process and FilingReview process,
> in
> order to review
the court record and to pre-populate or validate a
> filing's
> data.
>
>
> Eric and I chatted this
morning, and here are some directions I gave him:
>
> 1.
In general, strike the use of 'This-n-That Component' in our
>
user-oriented use cases. Instead, refer to the users' interaction with
> the
> 'System'. I think the results will be a better
story.
>
> 2. Rather than creating component-oriented use
cases, we should document
> the
> component interactions
with UML 'collaboration diagrams' and/or, my
> favorite, 'sequence
diagrams'. The UML diagrams will provide a better
> picture of
how the underlying parts-and-pieces are intended (by LegalXML)
>
to
> fit together. (and, of course, how these parts fit together
can be the
> subject of much debate. So be it. Still, UML will
be a structured way to
> express our opinions and proposals)
>
> Here, I might have stepped on toes or overstepped my
bounds. My apologies
> if I have. Still, my suggestion stands
and I would like to hear if anyone
> disagrees.
>
>
> 3. Where a user's actions with the System is
likely/capable of being
> facilitated by specific component
interactions, the user-oriented use
> cases
> will make a
reference to the documentation of the component interaction.
> So,
for example, if the use cases states "Filer Transmits Filing to
> Court'...then the use cases should have a reference to
documentation
> concerning HOW the 'Filing Review Component' and
its 'ReceiveFiling' (aka
> SubmitFiling, ReviewFiling, DoMyFiling)
interface are intended to operate
>
> 4.The functional
definition of what data needs to be transmitted, managed,
> or
transformed during a user's process should be defined in the
>
user-oriented use cases. In contrast, the component documentation will
> concern itself with the technical representation of the data and
actions.
> For example:
>
> Our 'submit a filing'
use case, should document what SPECIFIC functional
> data needs to
be transmitted to the court.
>
> For us to say 'filer
transmits filing' and then hope that the DOJ's schema
>
documentation has defined 'filing' well enough for us, is not going to
cut
> the mustard Why? The DOJ filing is probably overkill in
most places, and
> underkill in others. We'll never know what we
should use, or can't use,
> until we clearly list our functional
requirements for our LegalXML
> data-things.
>
>
The use cases need to say that the filing, with respect to THIS
process,
> specifically includes 'timestamp-this, and person-that,
and
> lists-of-these-and-those-things'.
>
> Then,
the component documentation can define how to technically express
> those functional things that have been listed in the use cases.
>
>
> That's the gist of the directions I have
given Eric for the next draft of
> the use cases.
> If you
have serious disagreements with what I have suggested, speak them
> soon - Eric is working on this stuff right away (as we speak).
But, also
> keep in mind, it's JUST another draft, and there will
be time for further
> comment after it is posted. (i.e. you might
want to see what it looks like
> before you poo-poo it?)
>
> - Shane
> Lexis Nexis
>
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]