[legalxml-courtfiling-cms-api] FW: Revised QnR Spec

["Rowley, Moira" <Moira.Rowley@acs-inc.com>]

Title: FW: Revised QnR Spec

The attached spec was revised by Dwight Daniels following our 7/30 conference call.  Please review and post your comments by Wednesday 8/14/02.

Moira Rowley

-----Original Message-----
From: Daniels, Dwight R [mailto:drdaniels@kpmg.com]
Sent: Tuesday, August 06, 2002 1:52 AM
To: Rowley, Moira
Subject: Revised QnR Spec

*****************************************************************************
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.        
*****************************************************************************

 

--- Begin Message ---

• To:
• Date: Tue, 6 Aug 2002 19:02:11 -1200

 

Moria,
 
Here's the revised version of the QnR spec for posting and distribution.
I've also responded to Tom's comments as well. My responses are embedded in
Tom's email.
 
Dwight
 
-----Original Message-----
From: Rowley, Moira [mailto:Moira.Rowley@acs-inc.com]
Sent: Tuesday, July 30, 2002 1:27 PM
To: 'shane.durham@lexisnexis.com'; 'steve.spohn@jud.ca.gov';
'lcoody@courtspecialists.com'; 'christopher.smith@jud.ca.gov';
'drdaniels@kpmg.com'
Subject: FW: QR Spec: Comments



Tom Smith's comments that we will discuss in email and in our next meeting.
I will also post to the OASIS list. - Moira
 
-----Original Message-----
From: T J Smith [mailto:TJSmith@itdecision.com]
Sent: Tuesday, July 30, 2002 3:38 PM
To: Moira Rowley
Subject: QR Spec: Comments


Here are my remaining comments re: the draft Q&R spec. Quoted material is
from the spec so as to provide context. Italicized stuff is my comment. In
the event it looks like garbage (format, not intellectual content of course)
I've attached a version in Word.
 
 
1.       1.2 BM__Toc485445115BM__Toc13296972Document Description: "This
document includes a DTD that is to be used to validate the syntax of XML
documents used to retrieve information from a court." 
This document also includes Policy XML DTDs. Confused me for a bit. 
[DRD] Modified document description to include a reference to this.  
 
2.    3 Element Specification:

b.      3.1.1 Query Name: Do we need version control to handle evolution of
Q&R DTDs?[DRD]  I'm not sure but I don't think so. I would envision most, if
not all, changes being in the area of the so-called "standard queries,"
whose number may grow. But this would be documented in the QnR spec and
would not affect the DTDs themselves.

c.      3.1.3 Privilege:  "If a privilege level is submitted with the query,
the court is free to ignore it."
No - in our model the court must be guiven the filer's privilege level to
help decide if it should honor the query. Need to accomodate both models.
[DRD] Both models are accomodated. Any other statement forces the CA model
on everyone. CA is free to insist that a court be given this information.
However, since the court must first disclose this information, I personally
believe this to open the door to major security breeches and consider this a
severe defect in the CA model. Since Shane and I seem to be on opposite ends
on many issues, I want to point out that I agree with him on this one, but
that he and I would seem to be in the minority.

d.      3.1.4.1 Parameter: "Wherever possible, the parameterName should
coincide with the established elements and attributes of the LegalXML data
dictionary and contain the same information." 
Where's that dictionary?
[DRD] I don't remember exactly where it is (though I do have a hard copy
version of it), or even if it's ever been posted, but I'm referring to the
reconciliation dictionary, which, as I understand it, is a living document.
There also is/was a dictionary subgroup.

3.       3.2 Response: Don't we need a way to associate a response to a
given query?[DRD] Why? Are we envisioning questions being submitted but not
responded to until some later date? I don't think we need this. At least I
don't see any compelling reason for it.

4.   3.3.1. getActorRole: "The getActorRole query is used to retrieve the
role of an actor involved in the case, e.g., a party or an attorney, and
that actor's privilege level to view case information."
This presupposes the court modifies its CMS to track filers & privileges; in
CA, we wish to require EFSPs to perform that function. Same issue as
3.1.3.[DRD] No, I don't think it does. It only presupposes that each CMS has
some record of the parties to a case and the access level that is associated
with their role on the case. Also, though I understand the reasoning behind
the desire to keep the number of changes required of CMS vendors at a
minimum, I don't think changes can be avoided altogether. At some point the
CMS vendors are also going to have to step up to the plate. I also think we
underestimate the willingness of CMS vendors to do so.
5.    3.3.7. getCourtPolicy: "The getCourtPolicy query is used to retrieve
the court's Court Policy XML document." 
No - thought we'd agreed at one point that access to Court Policy XML should
be outside the API. The API talks to the CMS, and the CMS knows nothing
about Policy XML.[DRD] Something needs to know about Policy XML, whether it
be a module put in front of the CMS or that is part of the CMS. Also, the
current version of the CMS API spec lists getCourtPolicy as a "candidate
predefined query." No official word exists on the "candidates" as to which
were elected and which were voted down. In my opinion, we either honor them
all or we honor none of them. 
6.    Missing Queries?   [DRD] The so-called "missing queries" are not in
the current version of the CMS API spec. I refer you all to p. 4 n.2 of the
QnR spec for my view of what the CMS API document constitutes. 

a.      Filer registration functions missing: RegisterNewActor;
InactivateActor.

b.      See table below. 

 

 


QR Draft Standard 2-10-2002

QR Draft Standard 7-1-2002

CMS API 


Get actor status (actorStatus)

GetActorRole?

GetActorStatus


Get associated case list for a particular actor (associatedCases).

GetAssociatedCases

GetCasesForActor


Get case calendar (caseCalendar).

getCaseCalendar

GetCalendarForCase


Get a specific case document, with or without any attachments
(caseDocument).

getCaseDocument

GetDocument

 


Get case history (caseHistory). 

getCaseHistory

GetCaseHistory


Get case information (caseInformation).

getCaseInformation

GetCaseInformation


Get court policy (courtPolicy).

getCourtPolicy

 


 

 

GetAttorneyForParty


 

 

GetDocumentListForCase


 

 

GetMatters-ActionsOfCase


 

 

GetFilingFee


 

 

RegisterNewActor


 

 

InactivateActor



 

 

Tom Smith
IT\Decision/CEFTS Program, CA AOC
 <mailto:tjsmith@itdecision.com> tjsmith@itdecision.com
650.591.1795 (Ofc)
650.346.7689 (Mobile)
650.591.1425 (Fax)
 

Moria,

 

Here's the revised version of the QnR spec for posting and distribution. I've also responded to Tom's comments as well. My responses are embedded in Tom's email.

 

Dwight

 

-----Original Message-----
From: Rowley, Moira [mailto:Moira.Rowley@acs-inc.com]
Sent: Tuesday, July 30, 2002 1:27 PM
To: 'shane.durham@lexisnexis.com'; 'steve.spohn@jud.ca.gov'; 'lcoody@courtspecialists.com'; 'christopher.smith@jud.ca.gov'; 'drdaniels@kpmg.com'
Subject: FW: QR Spec: Comments

Tom Smith's comments that we will discuss in email and in our next meeting.  I will also post to the OASIS list. - Moira

 

-----Original Message-----
From: T J Smith [mailto:TJSmith@itdecision.com]
Sent: Tuesday, July 30, 2002 3:38 PM
To: Moira Rowley
Subject: QR Spec: Comments

Here are my remaining comments re: the draft Q&R spec. Quoted material is from the spec so as to provide context. Italicized stuff is my comment. In the event it looks like garbage (format, not intellectual content of course) I've attached a version in Word.

 

 

1.       1.2 Document Description: "This document includes a DTD that is to be used to validate the syntax of XML documents used to retrieve information from a court." 
This document also includes Policy XML DTDs. Confused me for a bit. 
[DRD] Modified document description to include a reference to this.  

 

2.    3 Element Specification:

b.      3.1.1 Query Name: Do we need version control to handle evolution of Q&R DTDs?[DRD]  I'm not sure but I don't think so. I would envision most, if not all, changes being in the area of the so-called "standard queries," whose number may grow. But this would be documented in the QnR spec and would not affect the DTDs themselves.

c.      3.1.3 Privilege:  "If a privilege level is submitted with the query, the court is free to ignore it."
No - in our model the court must be guiven the filer's privilege level to help decide if it should honor the query. Need to accomodate both models.
[DRD] Both models are accomodated. Any other statement forces the CA model on everyone. CA is free to insist that a court be given this information. However, since the court must first disclose this information, I personally believe this to open the door to major security breeches and consider this a severe defect in the CA model. Since Shane and I seem to be on opposite ends on many issues, I want to point out that I agree with him on this one, but that he and I would seem to be in the minority.

d.      3.1.4.1 Parameter: "Wherever possible, the parameterName should coincide with the established elements and attributes of the LegalXML data dictionary and contain the same information."
Where's that dictionary?
[DRD] I don't remember exactly where it is (though I do have a hard copy version of it), or even if it's ever been posted, but I'm referring to the reconciliation dictionary, which, as I understand it, is a living document. There also is/was a dictionary subgroup.

3.       3.2 Response: Don't we need a way to associate a response to a given query?[DRD] Why? Are we envisioning questions being submitted but not responded to until some later date? I don't think we need this. At least I don't see any compelling reason for it.

4.   3.3.1. getActorRole: "The getActorRole query is used to retrieve the role of an actor involved in the case, e.g., a party or an attorney, and that actor's privilege level to view case information."
This presupposes the court modifies its CMS to track filers & privileges; in CA, we wish to require EFSPs to perform that function. Same issue as 3.1.3.[DRD] No, I don't think it does. It only presupposes that each CMS has some record of the parties to a case and the access level that is associated with their role on the case. Also, though I understand the reasoning behind the desire to keep the number of changes required of CMS vendors at a minimum, I don't think changes can be avoided altogether. At some point the CMS vendors are also going to have to step up to the plate. I also think we underestimate the willingness of CMS vendors to do so.

5.    3.3.7. getCourtPolicy: "The getCourtPolicy query is used to retrieve the court's Court Policy XML document."
No - thought we'd agreed at one point that access to Court Policy XML should be outside the API. The API talks to the CMS, and the CMS knows nothing about Policy XML.[DRD] Something needs to know about Policy XML, whether it be a module put in front of the CMS or that is part of the CMS. Also, the current version of the CMS API spec lists getCourtPolicy as a "candidate predefined query." No official word exists on the "candidates" as to which were elected and which were voted down. In my opinion, we either honor them all or we honor none of them. 

6.    Missing Queries?   [DRD] The so-called "missing queries" are not in the current version of the CMS API spec. I refer you all to p. 4 n.2 of the QnR spec for my view of what the CMS API document constitutes. 

a.      Filer registration functions missing: RegisterNewActor; InactivateActor.

b.      See table below.

 

 

QR Draft Standard 2-10-2002	QR Draft Standard 7-1-2002	CMS API
Get actor status (actorStatus)	GetActorRole?	GetActorStatus
Get associated case list for a particular actor (associatedCases).	GetAssociatedCases	GetCasesForActor
Get case calendar (caseCalendar).	getCaseCalendar	GetCalendarForCase
Get a specific case document, with or without any attachments (caseDocument).	getCaseDocument	GetDocument
Get case history (caseHistory).	getCaseHistory	GetCaseHistory
Get case information (caseInformation).	getCaseInformation	GetCaseInformation
Get court policy (courtPolicy).	getCourtPolicy
		GetAttorneyForParty
		GetDocumentListForCase
		GetMatters-ActionsOfCase
		GetFilingFee
		RegisterNewActor
		InactivateActor

 

 

Tom Smith

IT\Decision/CEFTS Program, CA AOC

tjsmith@itdecision.com

650.591.1795 (Ofc)

650.346.7689 (Mobile)

650.591.1425 (Fax)

 

--- End Message ---

Attachment: QueryAndResponseStandard[Draft]2002_08_05.doc
Description: MS-Word document