There are many ways to follow a standard like PWG:
1. Study the specification (PDF document) and derive all your technical conditions from that while completely ignoring any xml schema.
2. Like '1.' but use the xml schema as a keyword reference.
3. Like '2.' but create real xml instances that are based on the xml schemas and incorporate the instances in your solution.
4. You may come up with other variations of the above.
Conexant follows path 3 to some degree.
We feel that any xml validation helps avoid quite a number of syntax and structural issues before you write any code. But that's our decision and not a template for others.
However that means that we indeed use the PWG schemas seriously.
That preamble may help understand why we will share 3 comments as our contribution to the SM3 effort.
Comment1 refers to xml namespaces.
In most if not all vendor extensions the PWG schemas allow elements to be added that are proprietary to the editor (e.g. Conexant).
Therefore you show '##other' as the namespace for those extensions.
That works fine.
However one cannot add any other PWG objects (defined in any included/imported PWG schemas).
While we are sure that has its reasons, we would not favor that.
Working with '##any' as the namespace for vendor extensions would allow flexibility while allowing people to reuse the elements that they have already used in other parts of the same xml instance, e.g. in the capabilities sections.
A simple example may be to refer to 'InputSource' (Platen/ADF) in Scan service descriptions.
I may want to use such an object in my vendor extensions. In my personal view I'd reference other PWG objects much more often than proprietary extensions.
One can workaround that problem with a little trick - and there are probably other ways to dodge the issue.
I've added a little sample schema that represents a Conexant specific extension with a 'isg' namespace.
You can find a VendorExtension element in there:
<xsd:element name="VendorExtension">
<xsd:complexType>
<xsd:sequence>
<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Note: an extension of namespace any must be the only element in the xsd:sequence.
Otherwise the schema becomes arbitrary.
This now gives me the requested framework in a xml instance to do something like this (just a small snippet):
<pwg:ScanServiceDescription>
<pwg:CharsetConfigured>utf-16</pwg:CharsetConfigured>
...
<pwg:VersionsSupported/>
<isg:VendorExtension>
<pwg:ServiceSpecificServiceDescription>
<pwg:JobConstraintsSupported>
<pwg:JobConstraint>
<pwg:ResolverName>PlatenMaxHeight</pwg:ResolverName>
...
I feel it would be more elegant to stay within the PWG namespace.
But there's always a way to get what you need.
Conclusion:
I am not requesting the PWG to change all namespace definitions of vendor extensions.
But I wanted to lay this design out with a proper technical background.
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."
**********************************************************************
---------------------------------------------------------------------