Hi Harry,
Thanks for your feedback. Comments on your CONS below:
(1) 'target' versus 'targetDevice'
- I suggest that TFM _remove_ the parameter from CreateJob
(and any other redundant parameters in PSI operations that we
reuse)
- the 'target' is the TFM service, period
(2) New Transform attributes
- Define their names and semantics in the new TFM Service spec
- For OCR, perhaps define an OCR Subunit?? (too specific??)
- Unfortunately, all the current Service default/ready/supported
attributes are only in the Printer object in the SM schema
- TFM _really_ needs to define 'Transform' and/or 'Service' objects
that then (oddly) include many attributes where the term 'Printer'
is meant to be read as 'Service'
- Or we could redefine all those attributes with better names, but
that is a BIG job
- Definitely, we should not define new IPP/1.1 attributes for
non-print services
(3) Distinguishing between TFM versus PSI interface
- A TFM Service interface must NOT run on PSI's port 3800, but
rather (just like IPPFAX) on a brand new IANA-registered port.
- Just like IPPFAX, there is no ambiguity. You are talking to a
TFM port or you are talking to a PSI port. No mixing, ever.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com]
Sent: Wednesday, June 02, 2004 11:53 PM
To: McDonald, Ira
Cc: 'pwg at pwg.org'
Subject: Re: TFM Svc as strict subset of PSI/1.0
Ira, first, thanks for sketching the proposal.
I see pro's and con's to leveraging this much of the existing semantic
model.
PROs
1. The document object is directly applicable
2. The CreateJob, ValidateJob etc. operations are general enough that it
seems appropriate to leverage them rather than define new (similar) ops
(CreateTransform)
CONs
1. I REALLY wish PSI had used "target" in place of "targetDevice"
(everywhere)!
2. Where do we describe the transform specific attributes such as HoldUntil,
KillAfter?
- Are you suggesting we extend IPP Job Template Attributes?
- But what if we run into some very transform specific attributes (ex. OCR
level)?
3. How does an application discover and/or distinguish between a Transform
Service and a Print Service?
----------------------------------------------
Harry Lewis
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems
http://www.ibm.com/printers
303-924-5337
----------------------------------------------
"McDonald, Ira" <imcdonald at sharplabs.com>
05/31/2004 02:48 PM
To
"'pwg at pwg.org'" <pwg at pwg.org>
cc
Harry Lewis/Boulder/IBM at IBMUS
Subject
TFM Svc as strict subset of PSI/1.0
Hi folks, Monday (31 May 2004)
PSI/1.0 _already_ supports very precise document transforms, via the
'requestedTargetDeviceDataType : DocumentFormatDetails' parameter
of the CreateJob method. This is the _same_ functionality incorporated
into the latest JDF/1.2 spec. A PSI client uses FetchDocumentDataByPull
or FetchDocumentDataByValue later to retrieve the transformed output.
ftp://ftp.pwg.org/pub/pwg/ps/wd/wd-psi10-20040113.pdf
Thus, here's a proposal to define a PWG Transform Service (TFM) as a
strict _subset_ of PSI/1.0 without Target Devices (and without _any_ new
features or Job/Document elements). The proposal is summarized by the
commented table of contents from the latest PSI/1.0 draft.
Rationale for proposal, from section 5.5.2 CreateJob of PSI/1.0 spec:
"targetDeviceIdentifier : URI
A URI that defines the Target Device that is to be associated with a
Job. See definition in section 7.2.
<...>
If the client specifies the Print Service's Service Root URL as the
targetDeviceIdentifier, then the Print Service is considered the final
destination, and the Print Service can perform all job processing. For
example, document transformation."
^^^^^^^^^^^^^^^^^^^^^^^
and later in section 5.5.2:
"requestedTargetDeviceDataType : DocumentFormatDetails
If this parameter is specified, then the Print Service shall transform
^^^^^^^^^^^^^^^
the source Document into the data type requested. If the specified
Target Device does not support the requestedTargetDeviceDataType, the
Print Service shall throw a ProcessingRequestUnsupported exception."
Comments?
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
------------------------------------------------------------------------
[Transform Service (TFM) subset of PSI/1.0 - per TOC of PSI/1.0]
5 Interface Definition
5.1 PSI Service Root URL
5.2 Negotiating a secure PSI connection
5.3 QueryEndPointsInterface
5.3.1 Interface Usage Examples
5.3.2 QuerySupportedInterfaces
5.3.3 QueryInterfaceDefinition
5.4 ServiceCapabilitiesInterface
5.4.1 Interface Usage Examples
5.4.2 GetTargetDeviceElements -- needed to query TFM Service elements
** delete ** 5.4.3 GetKnownTargetDevices -- TFM Service is only endpoint
5.4.4 ValidateReference
5.5 JobControlInterface
5.5.1 Interface Usage Examples
5.5.2 CreateJob
5.5.3 CloseJob
5.5.4 AddDocumentByReference
5.5.5 AddDocumentByPush
5.5.6 PushDocumentDataDelivered
5.5.7 AddDocumentByValue
5.5.8 GetJobs
5.5.9 GetJobElements
** delete ** 5.5.10 SetJobElements -- passive Jobs only
5.5.11 CancelJob
5.5.12 GetDocuments
5.5.13 GetDocumentElements
** delete ** 5.5.14 SetDocumentElements -- passive Documents only
5.5.15 CancelDocument
5.5.16 FetchDocumentDataByPull -- needed for client to retrieve output
5.5.17 PullDocumentDataFetched -- needed for client to retrieve output
5.5.18 FetchDocumentDataByValue -- needed for client to retrieve output
** delete ** 5.5.19 FetchJobs -- no Target Device support
------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/pwg/attachments/20040603/de019206/attachment-0001.html