I don't think so, but I'll be honest, I wouldn't know for sure unless I
actually tried it out. (*mutters bad things about XML Schema*)
Cheers,
- Dan
On 5/4/07, Polar Humenn <[EMAIL PROTECTED]> wrote:
Say I want to do this:
<xs:complexType name="Mytype">
<xs:complexContent>
<xs:entension base="sec:SSLServerPolicy">
<xs:sequence>
<xs:element name="crls">
<xs:complexType>
<xs:attribute name="file" type="xs:string"/>
<xs:attribute name="url" type="xs:string"/>
</xs:complexType>
<xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Basically extending SSLServerPolicy with another <element>. Would that
be prohibited if you used an <xs:all>?
Cheers,
-Polar
Dan Diephouse wrote:
> 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
