This topic covers the behavior of XML Schema generation. For example, you could use the schema generated from a message definition file to subsequently validate XML instance documents written by WebSphere Message Broker.
Lax generation affects how complex types that have Content Validation set to Open or OpenDefined or have Composition set to UnorderedSet are rendered in the generated schema. Note that such a validating schema will permit a wider range of messages than MRM parser validation.
<element name="xmlNameOfMessage"> <complexType> <sequence> <any processContent="lax" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType> </element>
Where Content Validation is set to OpenDefined, the following pattern is used. (The namespaces listed are all those defined in the containing message set.)
<element name="xmlNameOfMessage"> <complexType> <sequence> <any processContent="lax" minOccurs="0" maxOccurs="unbounded" namespace="http://www.ns1 http://www.ns2" /> </sequence> </complexType> </element>
<element name="xmlNameOfMessage"> <complexType> <sequence maxOccurs="unbounded" minOccurs= "(minOccurs of original sequence) * (items in original sequence)"> <choice> .. sequence contents .. </choice> </sequence> </complexType> </element>
Strict generation affects how complex types that have Content Validation set to Open or OpenDefined or have Composition set to UnorderedSet are rendered in the generated schema. Note that such a validating schema will permit a narrower range of messages than MRM parser validation.
Strict is the default generation option and generates a schema that matches the schema held in the message definition file, without the model extensions.
If an XML physical format is specified when generating the schema, the wire format customization is applied to the logical model. These properties control how an element in the model is actually rendered when it appears in a message for an XML wire format. See XML rendering options for the different render options available. A generated schema example is given below showing what is generated for the different render options available for local elements; note these examples do not modify the Namespace of any ID Attribute Name or Value Attribute Name properties and assume that all elements specified in the complexType1 are of schema built-in type string.
<xsd:complexType name="complexType1"> <xsd:sequence> <!-- Local element Render = 'XMLElement' --> <xsd:element name="localElement1" type="xsd:string"/> <!-- Local element Render = 'XMLElementAttrID' ID Attribute Name = 'id' --> <xsd:element name="localElement2"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="xsd:string"> <xsd:attribute name="id" type="xsd:string"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element> <!-- Local element Render = 'XMLElementAttrVal' Val Attribute Name = 'val' --> <xsd:element name="localElement3"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="xsd:string"> <xsd:attribute name="val" type="xsd:string"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element> <!-- Local element Render = 'XMLElementAttrIDVal' ID Attribute Name = 'id' Val Attribute Name = 'val' --> <xsd:element name="localElement4"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="xsd:string"> <xsd:attribute name="val" type="xsd:string"/> <xsd:attribute name="id" type="xsd:string"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element> </xsd:sequence> <!-- Local element Render = 'XMLAttribute' --> <xsd:attribute name="localElement5" type="xsd:string"/> </xsd:complexType>
The rendering of xsd:Attributes is not supported. The user can only change the name of the attribute.
These are modeled in the message definition file as elements with both minOccurs and maxOccurs set to 0 and have one of the predefined ComIbmMrm_xxx types. During the schema generation, the type of such elements is changed to the base type of the respective ComIbmMrm_xxx type.
If there are global simple types that inherit from one of these ComIbmMrm_xxx types, these are changed to inherit from the base type of the corresponding ComIbmMrm_xxx type.
Generated schema files will not have any occurrence of these ComIbmMrm_xxx types.
For example the global element with type defined below:
<element name="globalElement1" type="ns1:ComIbmMrm_BaseValueBinary"/>
will result in the generated schema file and a global element with the corresponding xsd base type as defined below:
<element name="globalElement1" type="hexBinary"/>