The only comment I'll make is the reason behind the definition of "xxxJobTicketCapabilities". This construct was created to map to the IPP "-supported" attributes. It was never intended to integrate constraints and resolvers within it. Constraints and resolvers were viewed as a layer above "xxxJobTicketCapabilities" just as they are in IPP.
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com
Office: +1 (585) 265-8755
Mobile: +1 (585) 329-9508
FAX: +1 (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701
-----Original Message-----
From: sm3-bounces at pwg.org [mailto:sm3-bounces at pwg.org] On Behalf Of Norbert Schade
Sent: Friday, February 14, 2014 11:28 AM
To: Semantic Model 3.0 Workgroup discussion list
Subject: [SM3] CNXT MFD NS0214 Comment3: xxxJobTicketCapabilities
This third comment relates to our efforts in working with constraints in general.
We have some concern with a term like 'JobTicketCapabilities'.
- The term job ticket typically is a collection of features with exactly one setting.
- The term capabilities typically is a collection of features with often more than one setting each.
When looking deeper into that object we see that when dealing with constraints and resolvers we can list more than one setting, which supports more the idea of exception handling for capabilities.
Fine with us.
When we look at sections like 'DefaultxxxJobTicket' we realize that allow exactly one setting - as expected.
It looks as if any constraints and resolvers are to be used for both capabilities and job tickets.
We can manage the remaining ambiguities in our code.
Another detail of constraints and resolvers is that one can define completely new fallback features resp. feature settings - some which have not even been defined in the capabilities section before.
Again, we can manage that in our code.
However other solutions (e.g. dependencies in UPDF as another PWG standard) worked with ID and IDREF fields instead which makes that part less error prone.
Conclusion:
Nothing we can't work around. Just some comments from our perspective.
If we misinterpret some aspects of the schemas, please help me understand better.
Regards
Norbert
Norbert Schade
Systems Engineer (printing)
Imaging Solutions
Conexant Systems, Inc.
201 Jones Road
Waltham, MA 02451
U.S.A.
Tel: 1-781-370-8929
Email: norbert.schade at conexant.com<mailto:norbert.schade at conexant.com>
Conexant E-mail Firewall (Conexant.Com) made the following annotations
---------------------------------------------------------------------
********************** Legal Disclaimer ****************************
"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you."
**********************************************************************
---------------------------------------------------------------------
_______________________________________________
sm3 mailing list
sm3 at pwg.orghttps://www.pwg.org/mailman/listinfo/sm3