MHonArc v2.5.2 -->
legalxml-courtfiling message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [legalxml-courtfiling] JXDDS Person Object
From: "Durham, Shane (LNG-CL)" <>
To: "'Poindexter, Gary W'" <>,"Durham, Shane (LNG-CL)" <>,Court Filing List <>
Date: Mon, 23 Sep 2002 11:02:20 -0700
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
