Ref attribute or Type attribute in XSD

Question

I've saw such a sample :

<xsd:element name="Product">
    <xsd:complexType>
        <xsd:sequence>
            <xsd:element name="ProductName" type="xsd:string" />
            <xsd:element name="Customer" type="xsd:CustomerType" />
        </xsd:sequence>
    </xsd:complexType>
</xsd:element>
<xsd:element name="CustomerType">
    <xsd:complexType>
        <xsd:sequence>
            <xsd:element name="FullName" type="xsd:string" />
            <xsd:element name="Age" type="xsd:string" />
            <xsd:element name="Age" type="xsd:occupation" />
       </xsd:sequence>
    </xsd:complexType>
</xsd:element>

And I wonder why someone would chose the one type instead of ref in such case:

<xsd:element name="Product">
    <xsd:complexType>
        <xsd:sequence>
            <xsd:element name="ProductName" type="xsd:string" />
            <xsd:element ref="Customer" />
        </xsd:sequence>
    </xsd:complexType>
</xsd:element>
<xsd:element name="Customer">
    <xsd:complexType>
        <xsd:sequence>
            <xsd:element name="FullName" type="xsd:string" />
            <xsd:element name="Age" type="xsd:string" />
            <xsd:element name="Age" type="xsd:occupation" />
       </xsd:sequence>
    </xsd:complexType>
</xsd:element>

What would be the positive side of using Type instead of ref, can anybody explain me? What I know is ref can also have minOccurs and maxOccurs option so you can define ref as arrays in deserialized code.

Answer 1

There are many ways to look at this. I guess it all began with some basic principles, such as consistency in the authoring style. From there, people started to analyse the implications of doing one way vs. the other; names were given: Russian Doll, Salami Slice, Venetial Blinds, The Garden of Eden. If you wish to find out more, a search about XSD authoring styles, also called design patterns for XSD, will yield a plethora of sites dealing on this subject. This link and this one are pretty good "fast-food"-like references I would start with... While I disagree with some statements there, e.g. contains only one global element (so, if I define a rq/rs schema for a Web Service, I wouldn't be compliant?) overall is a good starter.

In your case, consistently defining content models based on referenced elements is an indication of a "Salami Slice" pattern: all elements global, types local (anonymous). The first implication is that one cannot get rid of a namespace associated with a tag.

Not using referenced elements, but instead relying on local definitions, with types that are global, indicates a "Venetian Blind" pattern. In keeping with the namespace comment above, with this approach is now possible to control namespaces by setting the elementFormDefault attribute on the schema element.

The minOccurs/maxOccurs that are associated with particles, is not relevant here. For a global element, these attributes do not apply. For content model particles, elements being one kind, whether the element is refed or local, it makes no difference.