It looks like the problem discusssed in Re: MOD> "document-format-supported" [MOD needs clarification], http://www.findmail.com/list/ipp/showthread.html?num=3864 was addressed in the new MOD, ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-model-10.txt June 30, 1998. The new words say:
"If the Printer object does distinguish between different sets of supported values for each different document format specified by the client, this specialization applies only to the following Printer object attributes:
- Printer attributes that are Job Template attributes ("xxx-default" "xxx-supported", and "xxx-ready" in the Table in Section 4.2),
- "pdl-override-supported",
- "compression-supported",
- "job-k-octets-supported",
- "job-impressions-supported,
- "job-media-sheets-supported"
- "printer-driver-installer",
- "color-supported", and
- "reference-uri-schemes-supported"
"The values of all other Printer object attributes (including "document-format-supported") remain invariant with respect to the client supplied document format (except for new Printer description attribute as registered according to section 6.2).
While this new wording gets around the problem, I think it presents a poor model. It blatantly violates Second Normal Form, in that some Printer attributes depend on the (Printer identifier, document-format) tuple, while others depend only on the Printer identifier. The model says that all these attributes, including those that vary with document-format (e.g., number-up), are attributes of the Printer class of objects. But the implication is that each real-wold printer maps to a whole set of Printer object instances, selected by document-format. Attributes (e.g. printer-name) which don't vary with document-format are redundantly stored in each instance. Updates to attributes that don't vary with document-format (e.g. printer-state) require visiting all the instances.
A better model would split the existing Printer into two classes of objects: 1) a new, reduced Printer, and 2)something else that could be called "Interpreter". Then the attributes can be normalized between these two new classes. Attributes that don't vary with document-format are assigned to the Printer. Each real-world printer maps to one instance of Printer. Attributes that do vary with document-format are assigned to Interpreter. Each Printer instance contains one or more Interpreter instances, selected by document-format.
I know that IPP doesn't claim to be truly object-oriented. But I think considerations like this are important for a few reasons:
- IPP looks object-oriented, with terms like Object, and attribute, and Operation bandied about. It will lead to confusion if the IPP model is anti-object-oriented. Let's not call Printer an object if it represents something other than what an object is commonly understood to be.
- Many implementors are likely to use OO methods. (How about a poll of current implementors?) It would sure be nice if the IPP model could map easily to an OO design and implementation.
- Although an implementor's design could split up these classes internally and still meet the existing spec, there is some value in having the implemenation, the design, and the model trace cleanly back to the real world.
-Carl
-----
Original Message: http://www.findmail.com/list/ipp/?start=3867
Start a FREE email list at http://www.FindMail.com/