- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Wed, 14 Aug 2002 16:13:39 +0100
- To: xmlschema-dev@w3.org, Brenda Bell <bbell@juicesoftware.com>
Hi Brenda, > I've been watching this thread and originally came up with the same > assessment as Jeni... but then another thought occurred to me: the > fixed attribute makes more sense in the context of several facets > used together. Reconsider the password example where minLength is 5 > and maxLength is 20. Without the fixed attribute, you'd be able to > derive a type that says all passwords are 5 characters, yes? From an > application perspective, this imposes a limitation on passwords that > makes them easier to hack. Applying the fixed attribute to both > minLength and maxLength would prevent this... or at least -- slow > the hackers down. So in other words, the fixed attribute ensures that derived types enjoy the same full, diverse range as the base type. Interesting theory, but unfortunately there are several ways that you can get around that kind of restriction, for example: <xs:simpleType name="my-password"> <xs:restriction base="password"> <xs:pattern value=".{5}" /> </xs:restriction> </xs:simpleType> or, even sillier: <xs:simpleType name="my-password"> <xs:restriction base="password"> <xs:enumeration value="password" /> </xs:restriction> </xs:simpleType> Neither xs:pattern nor xs:enumeration have fixed attributes, so the only way to prevent this from happening is to make the password type final. As I think I've said before, the only use case I *can* think of for the fixed attribute is to specify that a certain enumerated value must always be allowed on every derived type, but that isn't possible because fixed isn't allowed on enumerations... Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
Received on Wednesday, 14 August 2002 11:13:41 UTC