W3C home > Mailing lists > Public > xmlschema-dev@w3.org > August 2002

RE: Is the fixed-attribute on length-facet useless?

From: Brenda Bell <bbell@juicesoftware.com>
Date: Wed, 14 Aug 2002 10:04:24 -0400
Message-ID: <846B0B02E1B78B49B678EDCC00EB2962FB50B7@mail01.ent.juice.com>
To: "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>
Hi Jeni and Rainer

> > Thinking about an use-case I get the notion of a password-type
> > (maybe with some sort of special feature ) in a schema, that serves
> > as a base for derived types. A fixed-attribute on minLength would
> > make sense, in order to prevent a user to derive a type by
> > restriction, that would allow a password with less than the
> > minLength value. Any use-case I can possibly think of goes in the
> > direction, how to protect a base type....
> Sure, but when you restrict the password type, the restricted type
> can't have a minLength that's *less than* the password's minLength in
> any case. The same goes for any other facet -- if a value is valid for
> a simple type, then it *must* be valid for its base type, by
> definition. The fixed attribute would allow you to prevent people from
> deriving types in which the minLength facet is *more than* the base
> minLength facet, but I just can't think of a time when that would be
> useful. Perhaps you can think of another use case?

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.
Received on Wednesday, 14 August 2002 10:04:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:04 UTC