RE: [courtfiling-reqts] Status, artifacts, issues

["Scott Came" <scott@justiceintegration.com>]

Thanks, Jim.

re: Juvenile...feel free to take the con (the Argo file and spreadsheet on KAVI are now
current), but perhaps announce on the list when you do so
re: missing Payment mappings...I would appreciate your
doing this...again, take the con whenever
re: CardAccount.accountOwnerAddress...ditto
re: UBL
schemas...ok

Regarding your response on the ServiceRecipient issue...I have to disagree.  The change that
I'm recommending, as far as I can tell, is pretty harmless, and saves us from having a ServiceRecipient association
all over the place in the model (wherever we have people and organizations.)  Also, the semantics are somewhat odd: 
"A person has or is associated with a service recipient."  If we're going to keep it as-is I'd at least like
to suggest changing the name ServiceRecipient to something that a person can have...like a "Service Profile"
maybe, or "Service Contact Means" or something like that.

> Scott,
> 
> Thanks
for all your work this week - truly above and beyond the call.
> Here are my responses to the issues you
identified.
> 
> --Associations in Juvenile not mapped; I took a stab at this (see more
>
below)
> 
> I will defer to John as the domain expert on the Juvenile issues.
> 
>
--(Payment mapping) Classes Branch and FinancialInstitution are mapped
> out in spreadsheet, but do not appear
in domain model...need to
> reconcile
> 
> We should add these to the domain model ala the UBL
Payment model.  Do
> you want to or should I?
> 
> --CardAccount.accountOwnerAddress is in
domain model, but not mapped
> 
> Move accountOwnerAddress to FilerPayment, make it type cac:Address
and
> 0,1.
> 
> --On GetServiceInformationQuery...
>   --shouldn't
ServiceInformationResponseMessage have 1..*
> ServiceRecipients
>   --shouldn't each ServiceRecipient
have either an Organization or
> Person?
>   --if so, then can we use the abstract class technique
used elsewhere
> (e.g., case type-specific stuff) to model this, and map to a schema
> choice
compositor?
> 
> I wouldn't make any changes at this point.  ServiceRecipients only apply
> to
Electronic service so it is an optional property of Organization or
> Person, not the other way around.
> 
> --We need UBL schemas
> 
> I'll create the UBL schemas when we lock down the domain
model and
> mappings.
> 
>   jim
> 
> ________________________________
> 
> From: Scott Came [mailto:scott@justiceintegration.com]
> Sent: Monday, July 04, 2005 2:37
PM
> To: courtfiling-reqts@lists.oasis-open.org
> Subject: [courtfiling-reqts] Status, artifacts,
issues
> 
> 
> As you've all seen, I just posted a new baseline of the domain model and
> mapping to the main TC KAVI area.
> 
> The consolidation work and cleanup raised a number of
issues, in the
> attached. Also attached is a list of changes that were made to the
> criminal and
traffic models, to improve consistency and reuse of
> structures across the message models. (John and I had a
conversation
> about this yesterday and decided some refactoring would be worth the
> effort.) I have
saved baselines along the way, so none of the changes
> are set in stone. I believe they do make the models
(and mappings)
> clearer, more consistent, and less error-prone.
> 
> Our biggest remaining
gaps are:
> 
> * Finishing up the juvenile model and mapping (still some gaps
> there...Jim, I
have highlighted some issues for you in the attached
> issues file, at the top)
> * Modeling and
mapping GetCaseQuery
> * Domain expert review of the consolidated models and all of the
> mappings
(esp criminal, traffic, and juvenile)
> 
> I have not begun creating schemas. I've flat run out of
time this
> weekend, and also do not want to spend time on them if there are
> additional changes to
the mappings. I would guess it will take 6-8 hours
> to create the schemas from the mappings.
> 
> I also agreed with John that I would produce a short (1-2 page)
> description of the ECF 3.0
architecture, for inclusion in the IEPD
> overview document. Look for that mid-week.
> 
>
Thanks everyone.
> --Scott
> 
> 
>