Question

I am receiving the following validation error in the WebSphere MQ Broker Tool v7.0 when working with a generated .xsd:

a-props-correct.2: Invalid value constraint value '0' in attribute 'attrname'.

The relevant .xsd text is the usage of the attribute:

<xsd:complexType name="CTypeContent">
    <xsd:simpleContent>
        <xsd:extension base="xsd:base64Binary">
            <xsd:attribute name="attrname" type="BooleanType" use="optional" default="1" />
        </xsd:extension>
    </xsd:simpleContent>
</xsd:complexType>

And the definition of the attribute:

  <xsd:simpleType name="BooleanType">
    <xsd:restriction base="xsd:boolean">
      <xsd:pattern value="0|1" />
    </xsd:restriction>
  </xsd:simpleType>

I have Googled and found many discussions about SOAP and the like but that seems a bit off my project. I just want to ensure that the logic in the .xsd is well founded.

EDIT:

The error disappears if I remove the default piece of the attribute. This isn’t a solution for me – but perhaps it helps in a diagnosis.

Answer 1

The XSD snippets are valid, so the error you’re getting makes no sense. I believe it is rather a bug in your WMB software.

What version of WMB are you using?

Since you seem to be able to play with the XSD, it would also help with troubleshooting if instead of removing the default attribute, try to rewrite the pattern from one with the value of “0|1”, into two separate patterns, one with a value of “0”, and another with the value of “1”. I’ve seen before with other products from the same vendor where patterns associated with xsd:boolean fail miserably.

UPDATE: Since posting this, I’ve ran myself into this and other similar scenarios, and realized that schema processors behave differently while validating what seems to be basically the same thing: a schema that correct according to the spec, yet practically it describes an impossibility. And this is where things get interesting as to what correct is.

This case is a bit more subtle maybe, since it involves getting this and this right; basically if a default kicks in, it’ll use the canonical representation of the associated value (not the string in the default value!). Since 1 means True for a boolean, the canonical representation of that is the string true which now obviously doesn’t match the pattern (which deals with the lexical representation – string basically) 0|1 which in turn makes these two incompatible. Considering PSVI, an XML processor that is XSD aware cannot create valid XML when applying the default. This is what the error message says.

To show other imposibility that is not flagged by any XSD processor I am typically using, consider this particular snippet:

<xsd:complexType name="Test">
    <xsd:sequence>
        <xsd:element name="Impossible" type="Test"/>
    </xsd:sequence>
</xsd:complexType>
<xsd:element name="Test" type="Test"/>

It is impossible to create a valid XML out of this XSD, just as having a default=”1″ and attribute missing in your case (of pattern restricted to 0 and 1).

To me, both scenarios are somewhat similar to a code compiler catching (at compile time) a divide by zero condition – where it can.