MHonArc v2.5.0b2 -->
legalxml-courtfiling message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
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?
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.
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.
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.
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.
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.
>
> 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>
>
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]