[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC