This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
According to the specification @default-validation attribute could have only "preserve" or "strip" values: <xsl:stylesheet ... default-validation? = "preserve" | "strip" ... But @validation attribute could have one of following values: "strict", "lax", "preserve", "strip". At the same time specification has following line for non-schema aware processor: "A non-schema-aware processor is not able to validate input documents, and is not able to handle input documents containing type annotations other than xs:untyped or xs:untypedAtomic. Therefore, such a processor must treat any [xsl:]validation or default-validation attribute with a value of preserve or lax as if the value were strip." - So it looks like "lax" is possible value for @default-validation Q: Should specification allows "strict", "lax" validation types for @default-validation attribute?
I think the decision not to allow "lax" or "strict" as valid values for default-validation was paternalistic; they aren't allowed because they would not very often be useful. They could also impose an excessive performance overhead if the processor doesn't find a way to avoid validating elements at every level of the tree. It's quite hard to optimize away the redundant validation in the general case, so I'm inclined to stick with the status quo. As for the current text, saying Therefore, such a processor must treat any [xsl:]validation or default-validation attribute with a value of preserve or lax as if the value were strip. is probably a bit careless and should change to Therefore, such a processor must treat any [xsl:]validation attribute with a value of preserve or lax, or any default-validation attribute with a value of preserve, as if the value were strip.
(In reply to Michael Kay from comment #1) > I think the decision not to allow "lax" or "strict" as valid values for > default-validation was paternalistic; they aren't allowed because they would > not very often be useful. They could also impose an excessive performance > overhead if the processor doesn't find a way to avoid validating elements at > every level of the tree. It's quite hard to optimize away the redundant > validation in the general case, so I'm inclined to stick with the status quo. > > As for the current text, saying > > Therefore, such a processor must treat any [xsl:]validation or > default-validation attribute with a value of preserve or lax as if the value > were strip. > > is probably a bit careless and should change to > > Therefore, such a processor must treat any [xsl:]validation attribute with a > value of preserve or lax, or any default-validation attribute with a value > of preserve, as if the value were strip. Thank you for yours response. I understand the reason of why @validation and @default-validation could have different value. So "lax" or "strict" and not allowed values for @default-validation and processor signals XTSE0020 error.
Agreed to make no change other than the clarification to the careless wording suggested in comment 1.