OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

courtfiling-reqts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]