The reason that things are typically a sequence, is so they can be
extensible. That is, you can't specify an xs:any for forward compatability
if you're using an xs:all. With that said, we don't have any xs:any's
declared anywhere, so it really doesn't matter.
Can you please create a JIRA issue for this? I concur that we should
probably change this as well.
- Dan
On 5/3/07, Bolton, Fintan <[EMAIL PROTECTED]> wrote:
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
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
