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

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:]
Sent: Tuesday, July 30, 2002 1:27 PM
To: ''; '';
''; '';
''
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:]
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:> 
650.591.1795 (Ofc)
650.346.7689 (Mobile)
650.591.1425 (Fax)