Defect Report Number: Z39.50MA-DR0002

Source of Report: Mike Douglass

Submitted-to and Date: 12/96

Report Concerning: PeriodicQuerySchedule

Type of Defect: Technical

Reference in Document: EXT.2 ESFormat-PeriodicQuerySchedule

Nature of Defect: If the origin supplies a persistent query schedule that names a persistent query package rather than supplying a query, the origin need not supply any database names if they are in the persistent query. However, the only place to put them in the schedule is in the originPart. Shouldn't this field be in the notToKeep part with a corresponding field in the TargetPart? (In the same manner as the actualQuery field.)

More of a problem is additionalSearchInfo. Once the task package is built we lose the persistent query package name and there's nowhere to put the additionalSearchInfo.

Solution Proposed: The problem with the current definition is that the origin may omit the names, supplying a query package name (instead of an actual query) assuming that the same databases as are listed in the query package are implied. But then the target copies the actual query into the package (but not the database names), and the original query package name is not retained, and so the database names are lost. In the proposed revised definition below, if the origin supplies names, the target uses those; if the origin does not (in which case the origin has to supply a packageName and not an actual query) the target copies the databaseNames from the package.

Proposed Correction: The current definition looks like:

OriginPartToKeep ::=SEQUENCE{
   activeFlag         	[1] 	IMPLICIT BOOLEAN,
   databaseNames       	[2] 	IMPLICIT SEQUENCE OF InternationalString OPTIONAL,
   resultSetDisposition 	[3] ....
   ......

OriginPartNotToKeep ::= SEQUENCE{
   querySpec              		[1] ....
   originSuggestedPeriod		[2] .....
   expiration             		[3] .....
   resultSetPackage       		[4] ......

TargetPart ::= SEQUENCE{
   actualQuery         		[1] Query,
   targetStatedPeriod  		[2] ....
   expiration          		[3] ....
   resultSetPackage    		[4] ....
   lastQueryTime       		[5] ....
   lastResultNumber    		[6] ....
   numberSinceModify   		[7] ....

1. databaseNames
   • Remove databaseNames from OriginPartToKeep,
   • insert it in OriginPartNotToKeep (still optional), and
   • insert it in TargetPart (mandatory).
   The purpose of this change is to ensure that the database names end up in the package.
2. additionalSearchInfo
   • add additionalSearchInfo to OriginPartNotToKeep, optional
   • add it also to targetPart, also optional optional because there might not be any additionalSearchInfo, as opposed to database names -- there are always database names.
   So the new definition would look as follows:

   OriginPartToKeep ::=SEQUENCE{
      activeFlag             	[1] IMPLICIT BOOLEAN,
      resultSetDisposition   	[3] ....
      ......
   
   OriginPartNotToKeep ::= SEQUENCE{
      databaseNames       		[0] IMPLICIT SEQUENCE OF InternationalString OPTIONAL,
      querySpec              		[1] ....
      originSuggestedPeriod 	[2] .....
      expiration             		[3] .....
      resultSetPackage       		[4] ......
      additionalSearchInfo   		[5] OtherInformation OPTIONAL}
   
   TargetPart ::= SEQUENCE{
      databaseNames       		[0] IMPLICIT SEQUENCE OF InternationalString,
      actualQuery         		[1] Query,
      targetStatedPeriod  		[2] ....
      expiration          		[3] ....
      resultSetPackage    		[4] ....
      lastQueryTime       		[5] ....
      lastResultNumber    		[6] ....
      numberSinceModify   		[7] ....
      additionalSearchInfo 		[8] OtherInformation OPTIONAL}
   

   Status/Secretariat Response:

   • June 1998: Endorsed by ZIG.
   • January 1999: Circulated for review to SC 4 members; comments due April 30, 1999.

   ---

   Library of Congress