See below..
Regards,
Don
Donald L. Bergeron
Systems Designer
LexisNexis
donald.bergeron@lexisnexis.com
O 937-865-1276
H 937-748-2775
M 937-672-7781
From: Scott Came
[mailto:scott@justiceintegration.com]
Sent: Wednesday, July 27, 2005
12:41 PM
To: Electronic Court Filing
Technical Committeee; Bergeron, Donald L. (LNG-DAY)
Subject: RE:
[legalxml-courtfiling] Comment period for existing artifacts
Thanks, Don. Allow me to summarize your comments in terms of
changes to the artifacts...please check whether I have it right:
1. Many types and elements in the domain model have not been given
definitions. This should be pursued by the TC as a medium-priority task
(i.e., needs to be done, but shouldn't derail us). Some definitions will
require domain expertise; others will require technical expertise.
SC comment: Solicit domain expert input from the TC...any volunteers for this
task?[Bergeron] And one volunteer from each domain to manage completion of
this task. These resources should be outside of the core team.
2. Suggest renaming of classes DevelopmentPolicyParameters and
RuntimePolicyParameters in the CourtPolicy diagram to remove the plurals.
SC comment: In general I agree that classes should have singular names,
and plurality should be addressed with cardinality, but in this case, we've
lumped a number of parameters into a single class
(DevelopmentPolicyParameters), so the name seems appropriate. Like the
java.util.Properties class in Java. Suggest discussion on a conference
call.[Bergeron] Nah… You just gave enough of an answer.
3. Suggest changing cardinality of associations between
CourtPolicyMessage and the two "parameters" classes
(DevelopmentPolicyParameters and RuntimePolicyParameters) to 1..*. This
will effect allowing courts to have multiple profiles.
SC comment: I agree with the spirit of the suggestion, but would
recommend we accomplish it by adding an intervening class, called CourtPolicy,
that is 1..1 with the two "parameters" classes, and 1..* with the
message. This more neatly encapsulates the concept I think you're after.[Bergeron]
Seems right.
4. Suggest changing name of class FiduciaryCaseInformation in the
CivilFiling diagram to something that avoids a narrowly-defined legal term of
art.
SC comment: OK. Suggested alternatives? We'll need domain
expert input.[Bergeron] I think we get this out of people with legal domain
knowledge.
5. Suggest changing name of MarriageInformation in the DomesticFiling
diagram to DomesticLegalRelationship.
SC comment: Seems reasonable to me as a non-expert. Need domain
expert input.[Bergeron] Agree
6. Suggest adding cardinality information for each attribute and
association in the documentation.html file.
SC comment: This will be easy to do, and I'll do it.[Bergeron]
Thanks I think
it will add to the usability of the documentation.
>
> To the extent of time available I have scanned through the documentation
in
> the diagrams for the Court filing blue materials in the archive. There has
> been very substantial progress and maturing of both the model in the
> documentation. The allocation of resources to the items described below
> should be to the extent possible carried on by members not on the core team.
> Their focus should be to go forward in relating these to the profiles in
the
> nonfunctional requirements.
>
>
>
> Artifact under review Domain Model Documentation
>
> * General -- I'm assuming that all items satisfy this definition
> needed will need to be assigned and covered by the team. Since many of
them
> in that state are actually reused artifact sets such as person I believe
> that the definitions in those cases would be to just set the reused
objects
> into context within the model. The partitioning of this task should be
along
> the lines of those definitions that require court domain expertise and
those
> who require technical domain expertise.
>
> * development policy parameters -- I like but has been done here.
> However, we should look at our use of plurals in the names specifically
the
> use of the singular form on supported profile. Although not initially, I
> would expect that courts will be forced over time to support more than one
> profile.
>
> * Fiduciary case information -- since there are fiduciary
> responsibilities for attorneys and for a corporate officers in potentially
> employees as well has up or fiduciary relationships the use of this term
of
> art in such a narrow case may be problematic.
>
> * Marriage information -- I hate to say this I believe we need to
> change the name of marriage information to domestic legal relationship.
> Further, I believe we need to carry a domestic legal relationship
> classification. This will be especially true in states where marriage and
> domestic partnerships are legally supported within the same legal
> jurisdiction but with different acknowledgment of rights between the
> parties.
>
> * General -- consider, not in this case but in future use to add
> cardinality to this section. For example my comment about supported
profile
> versus supported profiles the documentation of the cardinality at this
level
> would reduce ambiguity.
>
>
>
>
>
> Blue GJXDM mapping spreadsheet
>
> * General -- I see that here you pick up the cardinality for the
> different items. This may be sufficient although from a user documentation
> standpoint we need to consider the question whether or some parts of the
> audience may only read a subset of the documentation artifacts and be
> misled. Note -- I am more comfortable with this documentation approach of
> this time.
>
> *
>
>
>
>
>
>
>
> Regards,
>
> Don
>
> Donald L. Bergeron
> Systems Designer
> LexisNexis
> donald.bergeron@lexisnexis.com
> O 937-865-1276
> H 937-748-2775
> M 937-672-7781
>
> _____
>
> From: John M. Greacen [mailto:john@greacen.net]
> Sent: Tuesday, July 19, 2005 2:08 PM
> To: Electronic Court Filing Technical Committeee
> Subject: [legalxml-courtfiling] Comment period for existing artifacts
>
>
>
> Scott Came has posted on KAVI the domain models, definitions, and GJXDM
> mapping spreadsheets for all of the ECF 3.0 messages. On the conference
> call that just concluded we agreed to vet those documents on the following
> timeframe:
>
>
>
> Comments and suggested changes from TC members by no later than the close
of
> business on Wednesday, July 27th.
>
> Review of the comments by the subcommittee of Cabral, Came, Clarke,
Greacen
> and Tingom by Sunday, July 31st.
>
> Resolution of outstanding issues identified by the subcommittee on a
> conference call at our regular Tuesday time, August 2nd.
>
>
>
> I have scheduled a conference call for that purpose as follows:
>
>
>
> Date Tuesday, August 2, 2005
>
> Time 1:00 pm Eastern time; 10:00 am Pacific time
>
> Call in number 1-605-528-8855
>
> Access code 2892164
>
>
>
> We also decided on the following additional steps:
>
>
>
> Jim Cabral will continue to moderate the eService discussion until it is
> resolved.
>
>
>
> A subcommittee of Bergeron, Came, Cusick, Durham and Leff will develop the
> requirements for an ECF 3.0 profile, using the WS I profile as a means of
> identifying all such requirements. This process will necessarily also
> refine the non-functional requirements.
>
>
>
> Complete minutes will follow in due course.
>
>
>
>
>
> John M. Greacen
>
> Greacen Associates, LLC
>
> HCR 78 Box 23
>
> Regina, New Mexico 87046
>
> 505-289-2164
>
> 505-289-2163 (fax)
>
> 505-780-1450 (cell)
>
> john@greacen.net
>
>
>
>