[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [legalxml-courtfiling] Proposed "person" object
My issue is not with the object model, it is with what model to propose. The court filing model based upon actor and role (which by the way, permits justice and business entities to have roles) works beyond court filing. Build the object model with those classes and subclasses instead of making new ones. Person may be too narrow a scope for the first proposal, but I understand limiting scope. I can't quote a great many implementations based upon the court filing DTD but I know that there are projects under construction that use it. Texas Online is an example. Camel case is a non-issue to me. Pick one and let's do it. John M caught my incorrect details like <personalIDNumber> vs PersonalIdentification - sorry if this caused confusion. The point is, the current standard is not PersonalID as in the GTRI proposal. Change for the sake of change unless they can provide some meaningful reason why PersonalID is superior to PersonalIDNumber. gary -----Original Message----- From: John Messing [mailto:jmessing@law-on-line.com] Sent: Thursday, August 29, 2002 9:50 AM To: John.M.Greacen" <john@greacen.net>"@p0016c25.us.kpmg.com Cc: Court Filing List Subject: Re: [legalxml-courtfiling] Proposed "person" object At one point in time, in 2001 I believe, we developed an operating principle for situations like this that paraphrased said a proponent of change bears the justification for making the change in order to balance a need for improving a standard against the risk of undermining prior work of the group. So, it seems that the group needs to affirmatively adopt the change in order for it to be effected, if this principle is still in effect. An object model is a cleaner and a more workable way in my opinion to express the relations between the subjects of court filing actions and their relationships to various other subjects and issues involved in a case. On the other hand, the way it was set up in Court Filing 1.0 is probably a sufficiently workable way of establishing and managing the relationships to make this improvement irrelevant. The question ultimately is the benefit of being consistent with the work of the justice groups involved the data dictionary project. One issue that comes to my mind is the question whether this change will be a final one, at least for a determinable time period, or the TC is looking at becoming reactive to the work of other groups, which I have a hunch could be a frustrating and ultimately unrewarding experience. ---------- Original Message ---------------------------------- From: "John M. Greacen" <john@greacen.net> Date: Thu, 29 Aug 2002 02:46:48 -0600 >In Salt Lake City, when we discussed the requirements for the Electronic Court Filing 2.0 specification we included not only moving to schema and considering SOAP and ebxml, but also making changes called for by the creation of this object-oriented data dictionary. So, we have already recognized the >likelihood of making significant changes, and that we will mark those changes by moving to a version 2 (which will not be backwardly compatible with version 1). > >And Messing is right that change at this level would have to carry through into Court Document and Q&R and CMS-API. > >The question for me is not whether to contemplate a change of this magnitude, but rather whether this would be a change for the better. Rolly says yes. Gary says no. What do others think? > >John Messing wrote: > >> The "role" approach is also found in QnR. That would also need to be revised in addition to CF and CD. What about CMS-API and Court Policy? How extensive are the changes, if any need to be made? >> >> The bright side (though it scarcely seems bright in light of the efforts that have been expended to date) is that there are few actual LegalXML implementations of CF. I know King County has some work done already in CF. How badly would a change impact existing implementations? >> >> Until we know these parameters, it is hard to weigh the cost/benefits of a change to an object model for a person or entity. >> >> Each of the other changes outlined by John, even the name case changes, has a destabilizing effect on potential or actual implementations that needs to be carefully assessed. It is not easy to plan or deploy applications with the basic standard rapidly changing, sometimes in seemingly contradictory ways. >> >> ---------- Original Message ---------------------------------- >> From: "Chambers, Rolly" <rlchambers@smithcurrie.com> >> Date: Wed, 28 Aug 2002 23:14:55 -0400 >> >> >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 >> > >> > >> > >> >> ---------------------------------------------------------------- >> To subscribe or unsubscribe from this elist use the subscription >> manager: <http://lists.oasis-open.org/ob/adm.pl> > >-- >John M. Greacen >Greacen Associates, LLC. >18 Fairly Road >Santa Fe, NM 87507 >505-471-0203 > > > ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ***************************************************************************** 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. *****************************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC