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:]
> Sent: Monday, July 04, 2005 2:37
PM
> To:
> 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
>
>
>
