> All,
>The Print semantics that we defined in IPP are being used throughout the
industry. The print system may be less functional (e.g. UPnP) or much more
complex (e.g. JDF DigitalPrinting). The important point is that whenever
possible the semantics are being reused. The reuse is a great benefit to
Printer manufacturers. It simplifies the logic necessary to incorporate our
devices into these various network environments. It speeds the definition
of printing protocols/systems since the semantics of common features need
not be reargued.
One of the barriers to the use of the PWG print model is its tight
association with IPP. In the definition of IPP we clearly separated the
model from the protocol. RFC2911 covers the base semantics. We also have
extensions to the model defined in some Internet Drafts and IEEE-ISTO PWG
standards. I believe we should split the IPP semantic model from the IPP
protocol. Using the "PWG Semantic Model" in discussions around industry
wide agreed upon print semantics avoids the "IPP baggage". I believe the
separation will foster reuse in various network printing environments and
standards. The separation will not affect compatibility with IPP.
To begin the conversation I though we might start with the definition of a
"PrintJob Ticket". The existing semantics has the Job Template Attributes
that cover most of a PrintJob Ticket. These cover the semantics of the
production instructions. There are some additional descriptive and control
attributes that are required. Examples include "jobName",
"jobRequestingUserName" and "attributeFidelity". These attributes are
normally held in an operation's Operational Attributes. Often there is a
direct mapping to a Job's Description Attribute as with "jobName". There
are cases where the mapping is simple between the Operational Attribute and
the Description Attribute as with "JobRequestingUserName" mapping to
"JobOriginatingUserName". We even have cases where there is no mapping such
as with "attributeFidelity". We have already agreed on the semantics. We
need to work out what a freestanding PrintJob Ticket will look like for the
PWG.
I have uploaded an XML schema definition for RFC2911. The schema includes
some types (e.g. rangeOfInteger), a Job and the elements that compose a Job,
namely Job Description and Job Template elements. Included is a sample
PrintJob Ticket based on the Job Template. I thought a conversation around
a Print Job and a PrintJob Ticket would be appropriate.
> Some rules I used in the schema mapping:
> 1) Data types are simplified where ever possible. ( "nameWithLanguage"
> becomes "string" with a length restriction)
> 2) For attributes (and operations) the '-' character is dropped and the
> following character is capitalized. ("job-name" becomes "jobName")
> 3) Attribute value strings remain the same.
> ("job-state-reasons"='job-printing' becomes
> "jobStateReasons"='job-printing')
> 4) Any attribute with the string "ipp" has the "ipp" string removed.
> ("ipp-attribute-fidelity" becomes "attributeFidelity")
> 5) All IPP attributes are represented as XML elements.
> 6) All attribute groups are represented as an ordered set of elements
> (i.e. sequence)
> 7) All enums are represented as strings using the string associated with
> the integer value. ("job-state"='3' becomes "jobState"="pending")
> 8) All type 1 enumes are represented as a "string" type with an
> enumerations restriction. (i.e. can not be extended)
> 9) All type 2 and 3 are represented as a "string". The standardized
> values are captured as appinfo annotations. (i.e. allows vendor and site
> extensions)
> 10) Multivalue attributes are represented as a single instance of an
> element that contains a sequence of elements (see "finishings" in sample
> PrintJobTicket or JobTemplate schema)
> 11) shema allows addition of new elements via "xsd:any" and places no
> restriction on namespace of addition.
>>>> Some PWG specific types:
> "ftp://pwg.org/pub/pwg/Semantic_model/typesPWG.xsd"> The Job:
> "ftp://pwg.org/pub/pwg/Semantic_model/Job.xsd"> The Job Description attributes(i.e. XML elements) for the Job:
> "ftp://pwg.org/pub/pwg/Semantic_model/JobDescription.xsd"> The Job Template attributes(i.e. XML elements) for the Job:
> "ftp://pwg.org/pub/pwg/Semantic_model/JobDescription.xsd"> A Sample Print Job Ticket based on Job Template attributes:
> "ftp://pwg.org/pub/pwg/Semantic_model/PrintJobTicket.xml">>I also have a 21 page PWG Semantic Model Overview document that I will send
out tomorrow. This version is limited to RFC2911. It is a very concise
semantic guide for those of us who are not IPP experts. It describes the
model, objects, attributes and actions as briefly as possible. It contains
references to RFC2911 sections for those who want the bloody details.
> Pete
>> Peter Zehler
> XEROX
> Xerox Architecture Center
> Email: PZehler at crt.xerox.com> Voice: (716) 265-8755
> FAX: (716) 265-8871
> US Mail: Peter Zehler
> Xerox Corp.
> 800 Phillips Rd.
> M/S 128-30E
> Webster NY, 14580-9701
>>> Though the printer is part of the schema I thought we would start with the
> Job and "PrintJobTicket" discussion. I have uploaded a version of a
> Printer Schema. I also have done some work modeling the operations and
> their associated messages. They are not ready to be shared yet.
> The Printer:
> "ftp://pwg.org/pub/pwg/Semantic_model/Printer.xsd"> The Printer Description attributes(i.e. XML elements) for the Printer:
> "ftp://pwg.org/pub/pwg/Semantic_model/PrinterDescription.xsd"> The Printer's Job Template attributes are represented in the schema as the
>> combination of PrinterDefaults, PrinterSupported and PrinterReady:
> The PrinterDefaults attributes(i.e. XML elements) for the Printer:
> "ftp://pwg.org/pub/pwg/Semantic_model/PrinterDefaults.xsd"> The PrinterSupported attributes(i.e. XML elements) for the Printer:
> "ftp://pwg.org/pub/pwg/Semantic_model/PrinterSupported.xsd"> The PrinterReady attributes(i.e. XML elements) for the Printer:
> "ftp://pwg.org/pub/pwg/Semantic_model/PrinterReady.xsd">>