Orthogonality in my view trumps having no use case.
There's no use case for multiplying by one; but 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 schema WG 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 in order 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. If you demand a use case, I could talk about code generation; but I don't think it does demand a use case.
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.
I'm rambling: 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.
Michael Kay
Saxonica
On 01/03/2022 23:52, Michael Kay wrote:Orthogonality, or to put it another way, avoiding arbitrary restrictions. If ID and IDREF are going to be among your set of data types, then why would you want to disallow people from using them on elements.
It's part of the way some people view XML. I struggle to find any use case for using ID or IDREF on elements. In fact, I would argue that adding an ID or IDREF attribute to an element type *is* "using it on elements".(Personally, I would have made "IDness" and "IDREFness" properties that are orthogonal to type. I can't see any good reason for
disallowing IDs of type integer or date.
If we accept IDs must be unique within the document, I have encountered many reasons, such as "integers" that aren't (ie leading zeroes), and dates that turn out later to need multiple occurrences.But the SGML and DTD legacy weighed strongly on the XSD designers.)
I am very glad they did.PeterOn 1 Mar 2022, at 23:32, Roger L Costello <costello@mitre.org> wrote:
Hi Folks,
DTD only allows attributes to be of type ID and IDREF.
XML Schema allows both attributes and elements to be of type ID and IDREF. Why? Is there a compelling use case for declaring an element to be of type ID? Is there a compelling use case for declaring an element to be of type IDREF?
/Roger
_______________________________________________________________________
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
_______________________________________________________________________
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
-- Peter FlynnCork 🇮🇪 Ireland 🇪🇺_______________________________________________________________________XML-DEV is a publicly archived, unmoderated list hosted by OASISto support XML implementation and development. To minimizespam in the archives, you must subscribe before posting.[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/Or unsubscribe: xml-dev-unsubscribe@lists.xml.orgsubscribe: xml-dev-subscribe@lists.xml.orgList archive: http://lists.xml.org/archives/xml-dev/List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
