[SM3] dev caps scan: identifying ID versus classifying ID

[SM3] dev caps scan: identifying ID versus classifying ID

[SM3] dev caps scan: identifying ID versus classifying ID

Norbert Schade Norbert.Schade at conexant.com
Thu Mar 6 14:59:49 UTC 2014


When using the general SM schemas, it is sometimes a bit difficult to extend the xml instance properly.
Let me give an example.
InputSource is quite a popular feature of a scanner, as each has at least a platen or an adf.
The corresponding ScanServices schema shows:

                                                                                <xs:element name="InputSource" minOccurs="0">
                                                                                                <xs:complexType>
                                                                                                                <xs:sequence>
                                                                                                                                <xs:element name="AllowedValues" type="InputSourceType" maxOccurs="unbounded"/>
                                                                                                                </xs:sequence>
                                                                                                </xs:complexType>
                                                                                </xs:element>

Now let me show you a snippet out of a UPDF schema (shortened for easy demonstration) that does something very similar:

  <xsd:complexType name="MediaInputTrayCheckRecord">
    <xsd:sequence>
      <xsd:element name="VendorExtension" type="updf:VendorExtension" minOccurs="0" maxOccurs="unbounded"/>
    </xsd:sequence>
    <xsd:attribute name="ID" type="xsd:ID" use="required"/>
    <xsd:attribute name="ClassifyingID" type="updf:MediaInputTrayCheckValue" use="required"/>
    <xsd:attribute name="StringID" type="xsd:IDREF"/>
  </xsd:complexType>

Now imagine a device that has 2 ADFs.

What I see as "AllowedValues" in SM corresponds much more to the ClassifyingID in UPDF, while UPDF also manages a (more or less anonymous) ID.
A ClassifyingID as well as the value for AllowedValues can be interpreted programmatically. And that's good.
An ID allows two objects with similar attributes to coexist. It's only purpose is to identify each object uniquely (such a parameter is likely tracked as 'current setting').
I cannot add such an ID next to the AllowedValues element (the fact that we have elements in one framework and attributes in the other is merely a style issue).

I only pick input source as a popular feature.
But I'm dealing with this sort of issue on a regular basis.

Generally wondering if some SM3 schema editing is going on, as I may spend some time at least studying that.
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." 

********************************************************************** 

---------------------------------------------------------------------



More information about the sm3 mailing list