PWG> RE: PWG Semantic Model

PWG> RE: PWG Semantic Model

PWG> RE: PWG Semantic Model

Zehler, Peter PZehler at crt.xerox.com
Wed May 29 08:25:11 EDT 2002


All,
I have fixed the link for the Job Template Attributes below.  I uploaded the
files in ASCII mode instead of binary.  The only other change is that the
element (i.e. PWG Attribute) names now all start with an uppercase.
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


>  -----Original Message-----
> From: 	Zehler, Peter  
> Sent:	Thursday, May 23, 2002 8:32 AM
> To:	'pwg at pwg.org'
> Cc:	Psi-Wg (E-mail)
> Subject:	 PWG Semantic Model
> 
> 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/JobTemplate.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"
> 
> 



More information about the Pwg mailing list