Bill,
> On Sep 21, 2014, at 9:50 AM, William A Wagner <wamwagner at comcast.net> wrote:
> ...
> It is also clear from the IPP Scan specification GetNextDocumentImages operation that a scan job can have multiple documents.
I don't think these are multiple document objects, however. Get-Next-Document-Images is a convenient way to pull one or more images/pages from the scanner, but from the point of view of the model they are part of one document object and would be delivered (in the case of push scan) as a single file.
>> The Cloud conference call comment is that FetchJob (corresponding to
> Destination, DestinationAccesses, and InputElements for Scan with no need to have a FetchDocument operation. This suggests that there is but one document (possibly with multiple destinations) in a Scan Job. Alternatively, it may be that the Input Parameters and Destinations for each one of multiple documents are defined in the CreateJob. This seemes inconsistent with the general Imaging Service model.
In the case of Scan, the CreateScanJob operation is instantiating a single scan job containing a single document object that may have multiple digital representations (e.g. PDF, TIFF, etc.) of the same images. Figure 3 on page 22 of the MFD Scan spec seems pretty clear on that point. This is similar to how the Copy and FaxIn services work (single document jobs).
Print, FaxOut, and Transform can support multiple digital document inputs (and thus multiple document objects).
I think the only inconsistency here is that some job services support multiple document objects and some don't. But I don't think that hurts the overall model - just something worth pointing out.
(and perhaps as well worth considering/mentioning that most Print and FaxOut service implementations only support single document jobs...)
> The IPP Scan specification definitely refers to multiple documents in one scan job. However, Figure 1 can be interpreted to mean that the only operation necessary for Scan is a CreateJob, with GetNextDocumentImages necessary if it is a Pull Scan Job. Indeed, InputAttributes is defined to be in the CreateJob request as well as are the Job Template attributes defining destination; but it does not appear that different InputAttributes and/or destinations can be specified for different documents.
I think the choice of reusing the "last-document" operation attribute in the response of Get-Next-Document-Images operation is causing confusion here. It really is (semantically) "last-document-image".
Pete, do you think this is worth an editorial change before publication, either the attribute name or the description ("indicating that the last document IMAGE has been reached")?
> [Also, Compression Accepted and Document Format Accepted are defined in CreateJob, but also in GetNextDocumentImages for Pull Scans. Can it be assumed that requests in GetNextDocumentImages takes precedence?]
I think this needs some clarification - you put those in Create-Job for a Push Scan and in Get-Document-Images for a Pull Scan.
> Do I correctly understand that, although there may be multiple documents in a scan job, they must all have the same InputAttributes and the same destination(s)? An alternate approach might have been to send a SetDocumentAttributes sent for each document to be scanned, which contained the input parameters and destination for each specific document/image file; that would have been consistent with the Model.
Currently you scan whatever is at the input source and send it to the destination(s) or pull the images with Get-Next-Document-Images. The only way to break things up is to create multiple jobs and specify the number of images for each job in the "input-images-to-transfer" member attribute.
> For Cloud, we need to decide whether we should reflect the Semantic Model (with which we should bet be consistent) or the IPP Scan Binding. Or do we need to change the semantic model?
The intent is that IPP Scan would update the SM definition of SM Scan, since SM Scan doesn't deal with Pull Scan.
> Also, a few minor editorial comments/questions I had while looking up stuff.
>> 1. Table 1 lists Get-Next-Document-Images and refers to PWG 5100.SCAN. I take it that this means to have the specification refer to itself, but it is confusing even if the proper number is inserted. Better to refer to the internal paragraph.
Agreed.
> 2. Figure 1 refers to the operation as GetNextDocumentImage rather than GetNextDocumentImages
>> 3. In para 7.1.1, under Group 2: Job Template Attributes is a reference to section 8.28.1.7.2. There is no such section (should it be 8.2?)
>> 4. Although the text makes a distinction between Print Jobs and Scan Jobs, section 8.2.1.1 refers to a Print Job.
Thanks for catching these!
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair