Hi Ira,
You brought up an important "ease-of-use" issue.
For duplicated attributes of "Supported" and "Default" attributes in
"Description" group of a service, I don't think it's good to require
administrator to replicate everything after changes in one group. Hence I
recommend the semantics should mandate that if administrator set a
Supported or Default attribute in the Description group, the service MUST
not only check the set of values or the value set is in range and also
ensure the same is set in the corresponding attribute in the Supported or
Default group for consistency. And Vice Sersa if the adminstrator changed
a default value in the Default group or a set of allowed values in a
Supported attribute, and the same attribute existed in the Description
group.
All,
Further issues? comments?
Thanks,
-Nancy
Ira McDonald <blueroofmusic at gmail.com>
09/20/2010 11:01 AM
To
Nancy.Chen at okidata.com, Ira McDonald <blueroofmusic at gmail.com>
cc
"Zehler, Peter" <Peter.Zehler at xerox.com>, mfd at pwg.org
Subject
Re: [MFD] Issue to resolve before publishing v1.111 <Response Requested>
Hi Pete and Nancy,
I generally agree with your conclusions, but...one question.
What are the required semantics of, e.g., the duplicated
DocumentFormatSupported and DocumentFormatDefault
(in JobTicket capabilites and Service description elements)?
Does changing one change the other?
The IPP intent of XxxSupported and XxxDefault in the
PrinterDescription were to allow Administrator control.
Does the Administrator have to set them both places?
(This reminds me of IPP parallel attributes yuckiness.)
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
Christmas through April:
579 Park Place Saline, MI 48176
734-944-0094
May to Christmas:
PO Box 221 Grand Marais, MI 49839
906-494-2434
On Mon, Sep 20, 2010 at 10:38 AM, <Nancy.Chen at okidata.com> wrote:
>> 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* <http://www.mailscanner.info/>, 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/90b4b7a7/attachment-0001.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20100920/90b4b7a7/attachment.htm>