Re: RE: The Law of Least Power

A W3C document, titled "The Rule of Least Power":

There is an important tradeoff between the computational power of a language and the ability to determine what a program in that language is doing. Computer languages range from the plainly descriptive (such as Dublin Core metadata, or the content of most databases, or HTML), through logical languages with limited propositional logic (such as access control lists, conneg content negotiation or regular expressions), to the nearly Turing-complete (PDF or some versions of SQL), through those that are in fact Turing-complete though one is led not to use them that way (XSLT, more powerful versions of SQL), through those that are functional and Turing-complete (Haskell), to those that are unashamedly imperative and Turing-complete (Java, _javascript_/ECMAScript or C). The Turing-complete languages are shown by computer science to be equivalent in their ability to compute any result of which a computer is capable, and are in that sense the most powerful class of languages for computers. The tradeoff for such power is that you typically cannot determine what a program in a Turing-complete language will do without actually running it. Indeed, you often cannot tell in advance whether such a program will even reach the point of producing useful output. Of course, you can easily tell what a simple program such as print "2+2" will do, but given an arbitrary program you'd likely have to run it, and possibly for a very long time. Conversely, if you capture information in a simple declarative form, anyone can write a program to analyze it in many ways.

Thus, there is a tradeoff in choosing between languages that can solve a broad range of problems and languages in which programs and data are easily analyzed. Computer Science in the 1960s through 1980s spent a lot of effort making languages that were as powerful as possible. Nowadays we have to appreciate the reasons for picking not the most powerful solution but the least powerful. Expressing constraints, relationships and processing instructions in less powerful languages increases the flexibility with which information can be reused: the less powerful the language, the more you can do with the data stored in that language.

Less powerful languages are usually easier to secure. A bug-free regular expression processor, for example, is by definition free of many security exposures that are inherent in the more general runtime one might use for a language like C++. Because programs in simpler languages are easier to analyze, it's also easier to identify the security problems that they do have.

More ... https://www.w3.org/2001/tag/doc/leastPower.html

-----Original Message-----
From: Roger L Costello <costello@mitre.org>
Sent: Tuesday, March 1, 2022 7:20 AM
To: xml-dev@lists.xml.org
Subject: The Law of Least Power

Hi Folks,

I would like to expand upon (generalize) something Michael Kay said [1] the other day.

An attribute is less powerful than an element. Attributes can't repeat, they have no order, and their values are simple strings whereas elements can repeat, they may or may not have a required order, and their values may be simple or complex.

A boolean type is less powerful than a string type. The value space of boolean is true, false, 0, 1 whereas the value space of string is virtually infinite.

Corollary: an attribute or element of type boolean is less powerful than an attribute or element of type string.

A string type that is constrained to a maxLength of 10 is less powerful than a string type that is constrained to a maxLength of 20.

We could continue to state XML constructs that are less powerful than other XML constructs.

Now we state the law:

        The Law of Least Power

Use an XML construct that has all the power
         you need and no more.

Comments?

/Roger

[1] http://lists.xml.org/archives/xml-dev/202202/msg00120.html

_______________________________________________________________________

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