Hi Folks,

Separate content from presentation. [1]

That is a design principle which we in the XML community have long espoused.

Today I learned another design principle: implement mechanism, not policy. [2]

Below are my notes on the mechanism-not-policy design principle. How would the design principle be applied to XML?  /Roger

Design Principle: Mechanism, Not Policy

Policy tends to have a short lifetime, mechanism a long one.

To create code that endures, implement mechanism, not  policy.

Policy versus Mechanism, Example #1

The following example illustrates the difference between policy and mechanism: [3]

An office has several employees. The office has this policy:

All employees need to be authenticated

before entering the office.

The policy describes what needs to be done without specifying how it can be achieved.

The policy could be enforced by one or more of the following mechanisms:

1.       RFID reader.

2.       Retina/fingerprint scanner.

The mechanism—RFID reader or fingerprint scanner—does not impose any limitations on the access policy (which employee needs to get access to which office area). Thus we can easily support new policies such as:

Employees working in group A should have access

to area X only between 9 AM and 5 PM.

Decoupling the mechanism implementation from the policy specification makes it possible for different applications to use the same mechanism implementation with different policies. This means that those mechanisms are likely to better meet the needs of a wider range of users, for a longer period of time.

Hardwiring policy and mechanism together has two bad effects:

(a)    It makes policy rigid and harder to change in response to user requirements.

(b)   Trying to change policy has a strong tendency to destabilize the mechanisms.

By separating mechanism and policy, it is possible to experiment with new policies without breaking mechanisms. We can also test the mechanism independently and thoroughly.

Policy versus Mechanism, Example #2

Here’s another example to illustrate the difference between policy and mechanism: [4]

The X windowing system strives to provide “mechanism, not policy”, supporting an extremely general set of graphics operations and deferring decisions about toolkits and interface look-and-feel (the policy) up to the application level (final choices about behavior are pushed as far toward the user as possible).

[1] https://en.wikipedia.org/wiki/Separation_of_presentation_and_content

[2] http://www.catb.org/esr/writings/taoup/html/ch01s04.html

[3] This example comes from: https://sites.google.com/site/mylokesh/policyvsmechanism

[4] This example comes from: http://www.catb.org/esr/writings/taoup/html/ch01s04.html