Ref atributo o atributos Type en XSD

Question

he vi una muestra tal:

<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> 

y me pregunto por qué alguien se eligió el lugar de typeref en tal caso:

<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> 

Lo Sería el lado positivo de usar Type en lugar de ref, ¿alguien me puede explicar? Lo que sé es ref también puede tener la opción minOccurs y maxOccurs para que pueda definir ref como matrices en código deserializado.

Answer 1

Hay muchas maneras de ver esto. Supongo que todo comenzó con algunos principios básicos, como la coherencia en el estilo de autor. A partir de ahí, la gente comenzó a analizar las implicaciones de hacer una forma vs. la otra; se dieron nombres: Muñeca rusa, Salami Slice, Persianas venecianas, El jardín del Edén. Si desea obtener más información, una búsqueda sobre estilos de autoría de XSD, también llamados patrones de diseño para XSD, arrojará una gran cantidad de sitios que tratan sobre este tema. Esta link y this one son referencias bastante buenas de "comida rápida" con las que comenzaría ... Aunque no estoy de acuerdo con algunas afirmaciones allí, p. contains only one global element (entonces, si defino un esquema rq/rs para un servicio web, ¿no estaría conforme?) En general es un buen iniciador.

En su caso, la definición constante de modelos de contenido basados ​​en elementos referenciados es una indicación de un patrón de "Remenda salami": todos los elementos globales, tipos locales (anónimos). La primera implicación es que uno no puede deshacerse de un espacio de nombres asociado con una etiqueta.

No usar elementos de referencia, sino confiar en las definiciones locales, con tipos que son globales, indica un patrón de "Persiana veneciana". De acuerdo con el comentario del espacio de nombres anterior, con este enfoque ahora es posible controlar los espacios de nombres estableciendo el atributo elementFormDefault en el elemento de esquema.

El evento minOccurs/maxOccurs asociado a partículas no es relevante aquí. Para un elemento global, estos atributos no se aplican. Para partículas de modelo de contenido, elementos de un solo tipo, si el elemento es ref ed o local, no hace ninguna diferencia.