SM> RE: IPP> "-actual" containment issue

SM> RE: IPP> "-actual" containment issue

SM> RE: IPP> "-actual" containment issue

Zehler, Peter PZehler at crt.xerox.com
Mon Oct 28 09:50:22 EST 2002


Dennis,
My comments below.
Pete

				Peter Zehler
				XEROX
				Xerox Architecture Center
				Email: PZehler at crt.xerox.com
				Voice:    (585) 265-8755
				FAX:      (585) 265-8871 
				US Mail: Peter Zehler
					        Xerox Corp.
					        800 Phillips Rd.
					        M/S 128-30E
					        Webster NY, 14580-9701



-----Original Message-----
From: Dennis Carney [mailto:dcarney at us.ibm.com]
Sent: Friday, October 25, 2002 10:33 AM
To: Zehler, Peter
Cc: IPP Discussion List (E-mail); PWG Semantic Model WG (E-mail)
Subject: Re: IPP> "-actual" containment issue 



Peter,

Some thoughts:
1) In IPP, I was thinking it would be best if the "-actual" attributes are
simply "normal" Job Description attributes.  Then they can be queried in
the same way, and follow the same conventions, as any other Job Description
attributes.
<PZ> I would think that we would want to allocate a new group tag for the 
encoding as well as defining a new attribute group tag for requesting these
new attributes. Putting them all into a group simplifies the processing 
since the entire unsupported group is ignored.<PZ/>

In the Semantic Model, you are proposing that they should instead be a new
group: that seems to make sense in the Semantic Model.  However, I think I
would have preferred, at least initially, that the JobProcessingActual
elements *act* the same as the JobDescription elements, and the
DocumentProcessingActual elements act the same as the DocumentDescription
elements.  In that case, JobProcessingActual would go under Job and
DocumentProcessingActual would go under Document.
<PZ> I don't see the downside of supporting a new group of attributes in
IPP as a proper attribute group. New implementations support the group
while old implementation ignore the entire group.  It allows access to
individual members as well as the entire group.<PZ/>

2) If we *did* go with your idea, what is the advantage to putting
"JobProcessingActual" and "DocumentProcessingActual" under a
"ProcessingActual" entry, rather than just putting them directly under Job?
<PZ> The main advantage I see is that the whole job history would stand
on its own.  Defined this way it would be possible to deal with "-actual"
data whether it came from a request on a Job object or through a separate
Job History interface offered by the Printer. <PZ/>

Dennis


 

                      "Zehler, Peter"

                      <PZehler at crt.xero        To:       Dennis
Carney/Boulder/IBM at IBMUS, "PWG Semantic Model WG (E-mail)" <sm at pwg.org>,
"IPP      
                      x.com>                    Discussion List (E-mail)"
<IPP at pwg.org>                                                            
                      Sent by:                 cc:

                      owner-ipp at pwg.org        Subject:  IPP> "-actual"
containment issue                                                          
 

 

                      10/25/02 04:49 AM

 

 





Dennis,

Attached is a diagram showing how the "-actual" objects could be
structured.
It puts the "ProcessingActual" elements in the Job.  The "ProcessingActual"
contains "JobProcessingActual" and a multivalued
"DocumentProcessingActual".
"ProcessingActual" identifies its Printer and Job.  Since there can be
multiple Documents, the "DocumentProcessingActual" identifies its
associated
Document.

Since the Job is the active entity is it appropriate to carry the Job
"Receipt"(i.e. "-actual") information there?

Pete

                        Peter Zehler
                        XEROX
                        Xerox Architecture Center
                        Email: PZehler at crt.xerox.com
                        Voice:    (585) 265-8755
                        FAX:      (585) 265-8871
                        US Mail: Peter Zehler
                                      Xerox Corp.
                                      800 Phillips Rd.
                                      M/S 128-30E
                                      Webster NY, 14580-9701



-----Original Message-----
From: Dennis Carney [mailto:dcarney at us.ibm.com]
Sent: Thursday, October 24, 2002 12:09 PM
To: Zehler, Peter
Subject: Re: IPP> RE: "-actual" containment issue



Peter,

Sounds good.

Dennis





                      "Zehler, Peter"

                      <PZehler at crt.xero        To:       "Zehler, Peter"
<PZehler at crt.xerox.com>, Dennis Carney/Boulder/IBM at IBMUS, "'ipp at pwg.org'"
                      x.com>                    <ipp at pwg.org>,
"'sm at pwg.org'" <sm at pwg.org>

                      Sent by:                 cc:

                      owner-ipp at pwg.org        Subject:  IPP> RE: "-actual"
containment issue




                      10/24/02 09:02 AM








Dennis,
I believe that new groups should be created for "-actual" just as there are
groups for "supported" and "default".  The "DocumentProcessingActual" group
should exist in both the Job and Document.  The "JobProcessingActual"
should
exist only in the Job.  This would parallel the processing elements nicely.
Pete

                                                 Peter Zehler
                                                 XEROX
                                                 Xerox Architecture Center
                                                 Email:
PZehler at crt.xerox.com
                                                 Voice:    (585) 265-8755
                                                 FAX:      (585) 265-8871
                                                 US Mail: Peter Zehler
                                                                     Xerox
Corp.
                                                                     800
Phillips Rd.
                                                                     M/S
128-30E

Webster NY, 14580-9701






#### job-actual.png has been removed from this note on October 25 2002 by
Dennis Carney






More information about the Sm mailing list