RE: [legalxml-courtfiling] Comment period for existing artifacts

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

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
> 
> 
> 
>