This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Bug #6446 points out that (minLength=1, length=6) is illegal unless the type happens to be derived from a type with (minLength=1). This rule and its consequence for this test shows why paternalism is bad. The minLength constraint here is redundant, whether or not it is present on the base type, and in both cases it does no harm. Requiring a processor to accept it in one case and reject it in the other is crazy - and the fact that this test result has gone unchallenged until now suggests that processors are not doing this properly. The rule that allows the combination (length, minLength) if minLength is unchanged from the base type is there because minLength might be automatically inherited from the base type. Essentially, because the constraint is at the component level, we don't know whether the facet was inherited or not, so it would be better not to guess. If we want to have rules that constrain the set of "locally-defined facets", we should put such rules at the XML representation level.
Just to illustrate the absurdity of the rules further: while it is legal to specify (minLength=1, length=6) on a type derived from NMTOKENS, because NMTOKENS has minLength=1, it is not legal to specify (minLength=1, length=6) on a type derived from NMTOKEN, because although NMTOKEN has a minimum length of 1, this is achieved using a pattern facet rather than a minLength facet.
Speaking for myself, I agree that the current rules are broken and should be changed. (My preference is to change them as part of a systematic effort to remove the ad hoc paternalistic rules of the spec.) But I note that the WG has in fact discussed either this precise question, or closely related questions, before, and established that (at least at that time) we could not achieve consensus either way on what to do about them. See, for example, the minutes of the meeting in Redmond in August, 2004 (discussion of RQ-147b) at http://www.w3.org/XML/Group/2004/08/xml-schema-ftf-minutes.html#id2608195 The minutes do not show, but I remember fairly vividly, that we spent an hour or two on the issue, and feelings ran rather high; they do show that we did not achieve any consensus at all. So my personal recommendation is to classify this issue, in view of the calendar date, as LATER. I'd like to resolve it, but I do not want to delay XSD 1.1 for a fruitless attempt to reach consensus on it, or even for a successful revision of the spec in this regard.