All,
I agree with Carl. I see a problem not only with the Interpreter, but also
with the Document. We may be able to resolve the Interpreter issue with
some clever wording. This will not be enough for the Document. As we begin
to address increasingly complex job rendering requirements(i.e. production
printing) we will need to bind attributes not only to jobs but to documents.
I believe that it is a good time to introduce proper Documents into the IPP
model.
Pete
Peter Zehler
XEROX
Xerox Architecture Center
Email: Peter.Zehler at usa.xerox.com
Voice: (716) 265-8755
FAX: (716) 265-8792
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 139-05A
Webster NY, 14580-9701
-----Original Message-----
From: kugler at us.ibm.com [mailto:kugler at us.ibm.com]
Sent: Thursday, July 15, 1999 11:27 AM
To: ipp at pwg.org
Subject: Re: IPP> OPS - Notes and Agreements on IPP Admin Ops from IPP
WG meeting,
<918c79ab552bd211a2bd00805f15ce850182df3- at x-crt-es-ms1.cp10.es.xerox.c
om> wrote:
original article:http://www.egroups.com/group/ipp/?start=5979
...
> 11. Set-Printer-Attributes operation: The "document-format"
operation
> attribute does have issues that were left unresolved. Issue of how
> to resolve with attributes that do and don't vary with regard to
> format. For example if I set n-up and media for a format of
> PostScript and then Get-Printer-Attributes with a document format of
> text, have I changed the values of n-up and media, or just n-up
> because its value depends on the format but not media which doesn't.
> The document format is a limited version of constraints. ISSUE: Do
> we continue the error with Get-Printer-Attributes by adding
> "document-format" to Set-Printer-Attributes or do we acknowledge
that
> an attribute holds all values, but some may be constrained by
> constraints which are another attribute to set.
>...
I think this issue could be resolved by clarifying some of the wording
in the Model doc in some future revision. This issue arises from a
flaw in the IPP data model.
In the OO methodologies I'm familiar with, one strives to get the data
model to at least Second Normal Form. It's against the rules to have
some Printer attributes identified by a (Printer identifier,
document-format) tuple, while other Printer attributes depend only on
the Printer identifier. Failing to correct this leads to the kind of
problems we see now with document-format.
We could correct this problem by acknowledging that there is really
another object class hidden in the IPP model: the Interpreter. A
Printer contains one or more Interpreters. When appropriate, the
"document-format" operation attribute is really part of the operation
target: it selects the Interpreter which the current operation is to
be applied. Some of those attributes currently called Printer
attributes -- the ones that vary with "document-format" -- should
rightly be called Interpreter attributes.
Simply explaining this in the wording might be enough to avert
confusion without any changes to the actual protocol.
BTW, I've been complaining about this issue for over a year now. See
http://www.pwg.org/hypermail/ipp/0708.htmlhttp://www.egroups.com/group/ipp/4162.html
-Carl