I'd like to conclude the constraints discussion from our (Conexant) perspective.
Part 1 (this email) is based on SM 1.185 which has to be used for the near future (assuming that 2.900 will be rather close to that as well).
In part 2 (a follow-up email) I will bring up some ideas/requests from a Conexant perspective for a more comprehensive solution in SM version 3.
My environment:
- In general I am working with the scan service these days.
- I've downloaded SM 1.185.
all PWG schemas live in C:\PWG\PWG-SM2-Latest1\Schemas.
as many paths are relative, the full path is not really important.
- I have created a tiny proprietary schema Gen.xsd that lives in a subfolder 'ISG' under the path above.
- I have created a sample xml instance CNXTScan1 based on that set of schemas.
that instance lives parallel to the Schemas folder in 'Instances'.
feel free to check the paths incl the one for the proprietary schema in this instance.
I stripped this instance down to the minimum to allow easy investigation.
Statement 1
The current instance validates in my XMLSpy.
A similar but more complex instance will be part of our fw.
We use the schemas to validate the instance (before compilation, not at runtime). The schemas are not part of the fw.
The scope of the sample instance
The attached sample instance supports 2 features (InputSource, Scanregion) specific to the scan service plus NumberUp - only to demo how features of the base class would show up.
It is not meant to be completely realistic but to demo the issues with constraints.
Caveats of SM 1.185 (this is based on my personal judgment and may not be correct in all aspects)
1. Namespaces
the PWG schemas use '##other' as the namespace for extensions.
I have created my own VendorExtension element in the Gen schema (the only reason to live for that little schema).
the namespace for extensions there is '##any'. My target namespace there is 'isg' (the name of my dpmt).
so when I want to reuse PWG elements in locations where they are not genuinely listed, I leave the pwg namespace and come back in with the isg namespace.
Works fine. Search for 'isg' in the instance.
2. constraints
Elements JobConstraintsSupported and JobResolversSupported (I will just refer to constraints objects below) are defined at the root level in the print service schema.
however JobTicketElements is of type PrintServiceCapabilitiesType and therefore not usable for me in the scan service.
constraints are also defined in the ServiceTypes schema - however not at the root level, but under ServiceSpecificServiceDescription. Not a problem, but it requires an additional layer.
the assumed specification in my sample manages 2 scan regions - one for ADF, a smaller one for Platen.
constraints are currently not defined in the scan service schema. So I had to use the workaround with the service types schema.
Attention! 1.185 schemas with constraints only support exactly one JobConstraint/JobResolver. I consider this an oversight (I had sent a separate email to the mailing list for that). That hopefully gets fixed quickly, as it's easy.
3. Base class ImagingDocumentProcessingCapabilitiesType only supports NumberUp (and the corresponding presentation type).
I wonder about the definition of a base class here.
if it only allows features that are supported by all services, the list does not seem very useful to me.
if it would allow features that are at least candidates for more than one service, that would look more appealing to me. but maybe I'm missing something here.
Note to item 2 above
If I'm right, a resolver of a constraint does not really have to fallback to a feature setting of the capabilities section. The schema does not validate if such a feature setting combination is really available in the capabilities section.
Yet in my sample I created 2 scan regions in the caps section. So the resolver can fall back to an existing feature setting.
Working with ID and IDREF offers a chance to validate that in xml (as used in UPDF dependencies). But that requires a little more work. Not a request at this point.
Please let me know, whether my sample and my comments make sense or if I should clarify anything more in detail.
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."
**********************************************************************
---------------------------------------------------------------------