As evidenced in the proposed updated charter for the IPP Working Group
(ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp-charter-20130821.pdf), that
workgroup has reconsidered several projects that had been identified,
placing the very reasonable criteria of requiring that use cases,
editors, and interested vendors be identified before proceeding. Most of the
suspended projects may be considered bindings of Imaging Service Semantic
Models for services other than printing (FaxOut was retained primarily
because it is basically done). During the discussion, there was some
comments of how this would affect the non-printer Imaging Service Model
efforts in SM3 and Cloud workgroups. I suggest that the potential impact of
this decision should be a primary topic to be considered at both Semantic
Model and Cloud Workgroup meetings on Monday, August 26. I offer the
following observations for consideration:
1. PWG Process says that there must be an announced prototype of any
specification before that specification can be considered Stable and put up
for PWG Last Call and Vote. Some have implied that, without an IPP
Prototype, a Semantic Model specifications of an Imaging Service cannot move
forward as a Standards Track document. However:
a. The Process does NOT specify to what degree the specification must be
prototyped.
b. The Process does NOT specify what constitutes a prototype of an
abstract model, although traditionally it has been the prototype of a
binding of the model. This delays approval of a Model and, to the extent
that implementers would want an approved model before they implemented it,
would be an unreasonable requirement. This has not been a problem in the
past because we have typically worked backward and documented the model
after the binding was done.
I suggest that, TO THE EXTENT THAT "USE CASES, EDITORS AND INTERESTED
VENDORS" may be identified, it is reasonable to have a model defining
project without an existing binding project, to treat the produced document
as a standards track specification, and to put that specification up for
vote without a prototyped binding.
2. With respect to Semantic Model efforts, the questions of use cases
and interested vendors may be addressed by considering the extent to which
the MFD Semantic Model has been applied in practice for Imaging Services
other than Printing. It has been suggested that there has been little or no
adoption. If this is true, and there is no significant vendor interest, then
one must seriously question the rationale in proceeding with an Imaging
Systems document (and the sanity of the editors).
3. Even without multifunction, it was suggested that an update to the
Print Model would still be needed. The counter to this might be that the
only binding in practice was IPP, that the update would just formalize what
has already been done in IPP (working backward again), that the significant
information already is in IPP documents and therefore that there is no need
for an updated printing model.
4. With respect Cloud Imaging System Modeling, the intent was to apply
and extend the Semantic Model to operation in a cloud environment for those
services to which that environment seemed to apply. Some Semantic Model
services have already been dropped from Cloud. Therefore, the criteria for
proceeding with services other than Print in the Cloud workgroup is not
just the identification of use cases, editors, and interested vendors, but
also the continued support of these services in the Semantic Model
workgroup.
Finally, although I think that the consistent modeling of imaging services
was a great idea, for various reasons it may not be the way the industry has
implemented or wishes to implement multifunction imaging services. IF that
is the case (and the IPP group has said as much), then we should recognize
this in our projects.
Thanks,
Bill Wagner