[MFD] Issue to resolve before publishing v1.111 <Response Requested>

[MFD] Issue to resolve before publishing v1.111 <Response Requested>

[MFD] Issue to resolve before publishing v1.111 <Response Requested>

Nancy.Chen at okidata.com Nancy.Chen at okidata.com
Mon Sep 20 14:38:12 UTC 2010


Hi Pete.

>I am a little confused by your second
>paragraph since capabilities should provide all the allowed values and
>default provide the single value used when not overridden in the user
>request. 

I thought that you were simply going to put <service>JobTicket and 
<service>DocumentTicket(without change)into service capabilities. I took a 
look at the current MFD XML Schema, the JobTicket elements in service 
capabilties already changed to contain "allowed values" instead. Sorry for 
the confusion.

>In IPP the support and default values of
>compression and the document format elements are properties of the
>service description.  Should the elements be replicated there as well?

I incline to say "YES" for consistency with IPP. Also they are REQUIRED 
attributes for Printer-Description. 

ALL: Anybody thinks it's too much redundancy? Please let us know.

-Nancy

--------------------------------------------------------------------------------------------------
Nancy Chen, PWG Vice-Chair
Principal Engineer
Solutions and Technology
Oki Data
2000 Bishops Gate Blvd.
Mt. Laurel, NJ 08054
Phone: (856)222-7006
Email: Nancy.Chen at okidata.com





"Zehler, Peter" <Peter.Zehler at xerox.com> 
09/17/2010 03:50 PM

To
<Nancy.Chen at okidata.com>
cc
<mfd at pwg.org>
Subject
RE: [MFD] Issue to resolve before publishing v1.111 <Response Requested>





Nancy,



You are right, I would need a parallel structure by introducing a
<service>ServiceDefaults that would contain the existing
Default<service>JobTicket and a new element for
Default<service>DocumentTicket.  I am a little confused by your second
paragraph since capabilities should provide all the allowed values and
default provide the single value used when not overridden in the user
request.  As for DocumentForma read on.



I have been doing some comparisons between the PWG SM v1 and the current
schema.  There are some defaults/supported values that are an issue.
This is because these values are associated with  Document Description
values or properties of the submitted Digital Document.  The elements in
question from the PWG Semantic Model v1 (and IPP) are the
PrinterDescription elements:



[CompressionDefault]  (Missing in SM v1)

CompressionSupported

DocumentFormatDefault

DocumentFormatSupported

DocumetFormatDetailsDefault

DocumentFormatDetailsSupported

DocumentFormatVersionDefault

DocumentFormatVersioSupported



The <service>Document Description contains elements for

Compression

DocumentFormat

DocumentFormatDetails

DocumentFormatVersion



So by implementing default and capabilities for <service>DocumentTicket,
the defaults/supported above would be covered there.



Right now the Capabilities and Default for PrintJobDescription are
missing the elements associated with:

CompressionSupplied

DocumentCharsetSupplied

DocumentDigitalSignatureSupplied

DocumentFormatDetailsSupplied

DocumentFormatSupplied

DocumentFormatVersionSupplied

DocumentMessageSupplied

DocumentNameSupplied

Impressions

MediaSheets



They will be added.   I got to thinking that FaxOut should have
compression and document format, and the others above, as well.  When
FaxOut is submitting a document (push or pull) these elements are
applicable.  (At least that will be my working group last call comment)



I think we should do #1 below and include a similar change to
<service>ServiceDefaults.    In IPP the support and default values of
compression and the document format elements are properties of the
service description.  Should the elements be replicated there as well?



Comments?







Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com <mailto:Peter.Zehler at Xerox.com>
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701



From: Nancy.Chen at okidata.com [mailto:Nancy.Chen at okidata.com]
Sent: Friday, September 17, 2010 12:34 PM
To: Zehler, Peter
Cc: mfd at pwg.org; mfd-bounces at pwg.org
Subject: Re: [MFD] Issue to resolve before publishing v1.111 <Response
Requested>




Hi Pete,

Depending on what we want tp provide for the
<service>ServiceCapabilities for Job and Document, I would say YES to
1), if users only want to know all the "features" available in a Job and
Document Ticket at Service level. Once we have all the features
supported, we also need a corresponding "default" for each supported
feature. I don't think we have a DedaultDocumentTicket at Service level
yet currently.

Would users not only want to know all those ticket "features" supported,
but also those supported "values" for each supported feature, such as
all supported Document Formats ?

DocumentFormat in a Job or Document Ticket only specifies the Document
Format value for a particular Job or Document. However, at a simple
request to a service, I would think users want to know all
DocumentFormat for all jobs and documents that are supported/configured
by a specific service instance before they submit a job to that service.


All,
What do you all think?

-Nancy

------------------------------------------------------------------------
--------------------------
Nancy Chen, PWG Vice-Chair
Principal Engineer
Solutions and Technology
Oki Data
2000 Bishops Gate Blvd.
Mt. Laurel, NJ 08054
Phone: (856)222-7006
Email: Nancy.Chen at okidata.com





"Zehler, Peter" <Peter.Zehler at xerox.com>
Sent by: mfd-bounces at pwg.org

09/17/2010 06:25 AM

To

<mfd at pwg.org>

cc


Subject

[MFD] Issue to resolve before publishing v1.111 <Response Requested>







All,



The issue I found is that <service>DocumentDescriptionCapabilities is
not represented in the model.  The <service>ServiceCapabilities element
contains, in effect, the capabilities of a <service>JobTicket.  That
does not seem to me to be the right place to "stuff" the
<service>DocumentDescriptionCapabilities.  I was thinking that if we add
<service>JobTicketCapabilities and <service>DocumentTicketCapabilities
directly under service>ServiceCapabilities we would then have a place
for <service>DocumentDescriptionCapabilities.  This has some advantages
such as a clearer mapping to the job or document ticket.  The downside
is that <service>DocumentProcessingCapabilities would be in both
capabilities.  I never thought of document processing  as potentially
being different at the Job and Document level but I suppose that is
possible.



What is your opinion?

1)      Add <service>JobTicketCapabilities and
<service>DocumentTicketCapabilities directly under
<service>ServiceCapabilities.  The former contents of
<service>ServiceCapabilities will move to
<service>JobTicketCapabilities.  <service>DocumentTicketCapabilities
will contain <service>DocumentDescriptionCapabilities,
<service>DocumentProcessingCapabilities and an extension point.

2)      Add <service>DocumentDescriptionCapabilities to
<service>ServiceCapabilities.

3)      Omit <service>DocumentDescriptionCapabilities

4)      Other (please specify)





Pete







Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com <mailto:Peter.Zehler at Xerox.com>
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701




--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


_______________________________________________
mfd mailing list
mfd at pwg.org
https://www.pwg.org/mailman/listinfo/mfd



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20100920/0f804702/attachment-0001.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20100920/0f804702/attachment.htm>


More information about the mfd mailing list