Question

I got the following XSD bit from a customer. It is part of a legacy schema that spans over dozens of files.

<xs:element name="stateProvinceName">
  <xs:complexType mixed="true">
    <xs:attributeGroup ref="xml:attlist.global-attributes"/>
  </xs:complexType>
</xs:element>

I'm trying to figure out what they actually want. There are no sub-elements, so what is the meaning of this 'xs:mixed'? is it supposed to be simpleContent, or no content?

I told them that they should use more standard construct, e.g.

<xs:element name="stateProvinceName">
  <xs:complexType>
    <xs:simpleContent>
       <xs:extension base="xs:string">
         <xs:attributeGroup ref="xml:attlist.global-attributes"/>
       </xs:extension>
     </xs:simpleContent>
  </xs:complexType>
</xs:element>

But they are not sure it means the same thing. Both schemas accept

<stateProvinceName ID="345643">California</stateProvinceName>

and

<stateProvinceName ID="345643"/>
Was it helpful?

Solution

The two types might be equivalent on the surface, but their extensibility is different. Using a simple content type of xs:string allows refinement of the type by constraining the string for example with a regular expression, while using a mixed complex content type with no elements allows refinement by adding elements to the model.

OTHER TIPS

The use of mixed with an empty content model is perfectly standard. If you don't like their content model, you'll need a different argument.

In general, mixed="true" means that character content is allowed among the child elements in a given complex type; in this case, since there are no child elements in the content model, the only legal content of the parent element will be character data, comments, and processing instructions. The upshot will be that the element declaration accepts the same set of elements as it would if the element were typed using a complex type with simple content declared as an extension of xs:string.

The choice between mixed-content and string is a design decision. In general, mixed content is better for natural-language prose, even if the initial design of an element does not foresee the need for sub-elements. In general, xs:string is easier to use if as the basis for restrictions of the set of expected values. (If you want to constrain the stateProvinceName to accept only the codes defined by particular postal services, xs:string is a better basis for your work than mixed content.)

It means that you have an element named stateProvinceName that has one or more attributes (as defined by xml:attlist.global-attributes) whose content is a string. As is, it's no different from the structure that you recommended.

Their potential difference, however, is their extensibility, as @Michael Kay noted.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top