RE: [legalxml-courtfiling] JXDDS Person Object

["Poindexter, Gary W" <gpoindexter@kpmg.com>]

Which rightly states an argument that I formulated but did not send. I agree
with the parent-child relationships that Shane describes instead of the
parent-child relationship proposed in the model.

gary

-----Original Message-----
From: Durham, Shane (LNG-CL) [mailto:Shane.Durham@lexisnexis.com]
Sent: Monday, September 23, 2002 2:02 PM
To: 'Poindexter, Gary W'; Durham, Shane (LNG-CL); Court Filing List
Subject: RE: [legalxml-courtfiling] JXDDS Person Object


Gary writes:
>> A judge is not a participant in an arrest but is a participant in a the
case that results from the arrest. <<

Ah.  Good topic indeed...  

In object structures (such as XML), a 'child' should NOT be tracking the
identity-of or relationship-to a 'parent'. 

So, I would say 'actor' should not contain 'role'.  And, an 'actor' should
NOT have an attribute that indicates if it is a 'case party' or
'non-case-party'. (I am using 'case' as a prefix so you understand my
meaning here.)


Instead, it is a 'parent' that should keep track of its children.. and the
relationship to those children.

The 'case' or 'filing' objects should keep track of the 'actors' to which
they are related.  It is the 'case' that is responsible for knowing which
'actors' are case-parties.  It is the 'filing' that is responsible for
knowing which actors are 'filing parties'.  So on and so forth.

The general OO prinicipal is this:
'Parents' keep track of their 'children'.
'children' don't keep track of their 'parents'.

This 'parent-owns-child' design pattern is a standard Object-Oriented way of
solving these multi-relationship problems and, in my opinion, is a must-have
characteristic for the next round of Object-Oriented LegalXML work.


Example: Please bear with my psuedo-code.

Instead of having structures like this (as we do now):

"Case-12 (id-1)"
"Gary    (id-2) ( plaintiff-of (id-1)  ) "
"Shane   (id-3) ( respondant-of (id-1) ) "

We should have:
"Case 12 (id-1) (participant-list: plaintiff-(id-2) respondant-(id-3) "
"Gary    (id-2) "
"Shane   (id-3) "


In this way, with parents keeping track of their children, the actors can be
related to more than one parent.  And, those actors could have different
parent-specific-relationships to each parent.

For example: in the same XML message, an actor might have a relationship to
a case, and a different relationship to a filing. 

"Case 12  (id-1) (participant-list: plaintiff-(id-2) respondant-(id-3) "
"Gary     (id-2) "
"Shane    (id-3) "
"Filing 5 (id-4) (participant-list: filer-(id-3) "


Some notes:
** If you are MOST familiar with relational databases, this OO concept may
seem backwards. That's because the OPPOSITE rules seem to be true in
database structures. In database tables, we typcially think of children
keeping track of the parents. And... that is usually appropriate in the
world of database tables. But, we must switch our thinking around when we
put our 'OO caps' on.

** One very-decent XML way to implement this "multi-parent-to-child"
approach is via 'id-refs', which allow multiple parents to contain
references to the same child.  Another important technique we should
implement: "XML-normalization", which is a standard XML approach for dealing
with nested object references.


- Shane




-----Original Message-----
From: Poindexter, Gary W [mailto:gpoindexter@kpmg.com]
Sent: Monday, September 23, 2002 10:08 AM
To: 'Durham, Shane (LNG-CL)'; Court Filing List
Subject: RE: [legalxml-courtfiling] JXDDS Person Object


Seems like an attribute for Actor/Party could provide the delineation
between participant and non-participant.

If we delineate, how is the relativity maintained as an event is
adjudicated? A judge is not a participant in an arrest but is a participant
in a the case that results from the arrest. Or does this matter because the
subject of the exchange changes and therefore the actor/party and their role
changes with the type and conditions of the exchange?

gary


*****************************************************************************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. 

If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement letter.         
*****************************************************************************