OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-courtfiling message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [legalxml-courtfiling] Proposed "person" object


I'm not sure about moving cheese - in fact I'm having trouble finding
it.
 
I checked the Justice and Public Safety XML Data Element Definitions
Draft 0.1.0 (April 26, 2002) 
( http://lists.oasis-open.org/archives/legalxml-sc/200205/pdf00000.pdf)
and confirmed that it does not include either an <actor> or a <role>
element, but does include a <person> element.
 
I also checked the Court Filing 1.1 Proposed Standard (22 July 2002)
(
http://www.oasis-open.org/committees/legalxml-courtfiling/documents/2207
2002cf1-1.pdf) and confirmed that it does not include a <person>
element, but does include <actor> and <role> elements.
 
All this checking also confirmed that both the Justice Data Element
Definitions (I'm assuming this is the current data dictionary -- the
"DD") and the CF 1.1 Standard include a <personalIDNumber> element and
that neither includes a <personalIdentification> element. This has me
wondering whether I'm looking at the same data dictionary and CF 1.1
standard that Gary has in mind.
 
On balance, I agree with the point that a person can have multiple roles
in a legal proceeding. Finding an effective way to use XML to describe
the various roles that a person can have is not easy. One reason for the
difficulty is that a role depends on context, which can change readily.
For instance, one person may be a child, daughter, sibling, sister,
parent, and mother in the context of a family; a witness, a plaintiff,
and a party in the context of a lawsuit; or a driver, an owner, and a
victim in the context of an auto accident.
 
I disagree that using multiple <role> elements to describe the roles of
a person or actor is better than using the proposed subclasses, such as
"plaintiff," "victim," or "witness." It is as easy to describe a person
as having the subclass "witness" (e.g. <person><witness/></person>) as
having the role of "witness"  (e.g.
<actor><role>witness</role></actor>).
 
One advantage of the subclass approach is that it provides greater
constraint and consistency in describing a person as a "witness". It
also provides more effective standardization - there would be only one
"witness" subclass element, but there could be "witness," "Witness," or
"WITNESS" role values based just on differences in capitalization. This
feature of the proposed subclass approach is a definite plus as I see
it. Using a <person> element also would align the CF 1.1 DTD more
closely with the Justice Data Element Definitions.
 
An obvious problem with the proposed "person object"/subclass approach
is that incorporating it would require change to the CF1.1 DTD, which is
inconvenient, even if it is a better approach. Also, the proposed
subclasses certainly would benefit from refining then to include more
meaningful names (which the proposal invites). Finally, the <person>
element clearly would not be appropriate to use to use for
organizations, such as corporations, associations, or partnerships, so
there would continue to be a need for element(s) containing information
about "non-persons."
 
I think the benefits of the proposed "person object" and subclass
approach weigh in favor of a change. I respect that others may find the
inconveniece of a change outweighs the benefits.
 
Rolly Chambers

	-----Original Message----- 
	From: Poindexter, Gary W 
	Sent: Wed 8/28/2002 9:22 AM 
	To: Court Filing List 
	Cc: 
	Subject: RE: [legalxml-courtfiling] Proposed "person" object
	
	
	As one who is working on a non-court filing implementation (i.e.
complaints) I find the court filing concepts of actor and roles far
superior to this proposal.
	 
	They made some name changes for no apparent reason. PersonalID
vs. PersonalIdentification - why? One of the basic concepts of the DD is
to not use abbreviations. Their first change substitutes a definitive
tag name with one that uses an abbreviation.
	 
	They changed PersonalIdentifiers to specific types of personal
identifiers. I find the flexibility of the current model superior to
what is proposed.
	 
	They have created a division through person classes that does
not work as well as Actor and Role. A police officer can be both the
"arresting officer" and a "witness." Their proposal does not appear to
permit this without creating two subclasses. With the current court
filing model I can create an Actor and give them two roles - one as an
arresting officer and one as a witness. It appears that I can create the
same structure with the proposed model, but why change the model unless
it has some superior qualities that I am not seeing.
	 
	Their model is probably workable, but it does not seem to be
superior to what we have in the Justice DD and the court filing DTD. I
am not willing to change unless there is purpose and value add from the
change. Don't move my cheese unless you can justify the move.
	 
	gary

		-----Original Message-----
		From: John M. Greacen [mailto:john@greacen.net]
		Sent: Tuesday, August 27, 2002 11:05 PM
		To: Court Filing List
		Subject: [legalxml-courtfiling] Proposed "person" object
		
		
		Please review this proposal carefully and get me your
comments.  Note the Sept 2 comment deadline. 

		In ECFS 1.0 and 1.1 we use an "actor" element which
encompasses persons, entities and things -- all of which can be parties
to cases (persons, corporations or associations, and ships, autos or
currency in in rem proceedings).  I have asked whether the proposed
"super object" is intended to serve the purpose of our "actor" element. 

		Are there other problems with the proposed structure of
this "person object" from our point of view? 

		-- 
		John M. Greacen 
		Greacen Associates, LLC. 
		18 Fairly Road 
		Santa Fe, NM  87507 
		505-471-0203 
		  

<<winmail.dat>>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC