RE: [courtfiling-reqts] Shane's Comments for Eric

["Eric Tingom" <etingom@tsquaredinteractive.com>]

Scott,

 

Yes i am very familiar with the current process for providing "technical" representation of the message content.  I will be following that same methodology for "Blue" because it seems to be the most effective.

 

Eric

---

From: Scott Came [mailto:scott@justiceintegration.com]
Sent: Thursday, February 10, 2005 3:43 PM
To: courtfiling-reqts@lists.oasis-open.org
Subject: Re: [courtfiling-reqts] Shane's Comments for Eric

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