I got the following XSD bit from a customer. It is part of a legacy schema that spans over dozens of files.
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.
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.
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.)