|
It has been a longstanding tradition in the SGML and XML community to express ID and IDREF values using attributes. In fact, DTD (which predated XML Schema) did not allow elements to be of type ID or IDREF; only attributes could be of type
ID and IDREF. When XML Schema was created they decided to allow both attributes and elements to be of type ID and IDREF. Why? Is there a compelling use case for declaring elements to be of type ID and IDREF? No. So why did they do it? The answer is orthogonality. Michael Kay explains: “Orthogonality (or, "no needless restrictions") says the lack of a use case is not a reason to disallow it.” “The concept of preventing you doing something because the language designers didn't think it was a sensible thing to do was known in the XML Schema working group as ‘paternalism.’ An example
of paternalism would be to disallow --1 (minus minus one) in XPath; or in regular expressions to disallow overlapping ranges [a-zi-k]. In my view, a rule that exists solely to prevent you doing something that's well-defined but useless is usually a bad rule.
Another example is the rule that concat() must have at least two arguments: I think that's a thoroughly bad rule.” “Of course there's a very fine line between paternalism and things like type-checking rules that are designed to protect programmers from their own errors. XPath 1.0 allowed you to write -1 <
0 < +1, and the result is false (because -1 < 0 is true, and true < 1 is false). XPath 2.0 disallowed that; a restriction that prevents you falling into an elephant trap isn't the same as a restriction that stops you writing expressions that aren't useful.
But XPath 2.0 doesn't stop you writing @x/@y: that's justified by orthogonality, but it's almost certainly a mistake. I think we should have made that a type error.” “Bottom line, I think: (a) Don't sacrifice orthogonality (introduce restrictions) just because something has no known use case (b) But do (sometimes) sacrifice orthogonality to stop users falling into elephant traps.” |