I agree, if there is some ordering requirement, extract the dependants into a nested sequence type, otherwise use xs:all. On an aside, could the SSLClientPolicy benefit from some refinement, possibly the introduction of nested types that encapsulate features rather than one long list of options?
Gary. > -----Original Message----- > From: Bolton, Fintan [mailto:[EMAIL PROTECTED] > Sent: 03 May 2007 11:47 > To: cxf-user@incubator.apache.org > Subject: xs:all instead of xs:sequence in configuration schemas > > From a user's perspective, I think it might be more > convenient to have Spring configuration schemas that make > more extensive use of xs:all instead of xs:sequence. > > For example, in the security configuration schema, the > SSLClientPolicy type is defined to be an xs:sequence, as follows: > > <xs:complexType name="SSLClientPolicy"> > <xs:sequence> > <xs:element name="Keystore" type="xs:string" minOccurs="0" > maxOccurs="1"/> > <xs:element name="KeystoreType" type="xs:string" > minOccurs="0" maxOccurs="1"/> > <xs:element name="KeystorePassword" type="xs:string" > minOccurs="0" maxOccurs="1"/> > <xs:element name="KeyPassword" type="xs:string" > minOccurs="0" > maxOccurs="1"/> > <xs:element name="KeystoreAlgorithm" type="xs:string" > minOccurs="0" maxOccurs="1"/> > <xs:element name="Ciphersuites" type="xs:string" > minOccurs="0" maxOccurs="unbounded"/> > <xs:element name="CiphersuiteFilters" type="tns:FiltersType" > minOccurs="0" maxOccurs="1"/> > <xs:element name="TrustStore" type="xs:string" minOccurs="0" > maxOccurs="1"/> > <xs:element name="TrustStoreType" type="xs:string" > minOccurs="0" maxOccurs="1"/> > <xs:element name="TrustStoreAlgorithm" type="xs:string" > minOccurs="0" maxOccurs="1"/> > <xs:element name="SecureSocketProtocol" type="xs:string" > minOccurs="0" maxOccurs="1"/> > <xs:element name="SessionCaching" type="xs:boolean" > minOccurs="0" maxOccurs="1"/> > <xs:element name="SessionCacheKey" type="xs:string" > minOccurs="0" maxOccurs="1"/> > <xs:element name="MaxChainLength" type="xs:long" > minOccurs="0" maxOccurs="1"/> > <xs:element name="CertValidator" type="xs:string" > minOccurs="0" maxOccurs="1"/> > <xs:element name="ProxyHost" type="xs:string" minOccurs="0" > maxOccurs="1"/> > <xs:element name="ProxyPort" type="xs:long" minOccurs="0" > maxOccurs="1"/> > </xs:sequence> > </xs:complexType> > > By declaring SSLClientPolicy as xs:sequence, you force the > user to specify the elements in precisely the specified > order. Now, while you have some hope of remembering the > names of the elements you need, it is unlikely that you will > be able to remember the required sequence for all of these > elements (unless you have a photographic memory). Also, most > users are used to the idea that they can set configuration > variables in a more or less arbitrary order. Ordering > mistakes would be particularly prone to occur when updating a > configuration file (say, for example, if an administrator > decided to add in a CiphersuiteFilter element). > > Element ordering would not be an issue, however, if the > SSLClientPolicy type was declared to be xs:all instead of xs:sequence. > > Does this make sense? Or are there some technical reasons > for preferring xs:sequence? > > Regards, > Fintan Bolton >
