Re: The Rule of Least Power

I second Michael on this one.

I like lean/agile design and development, although I am no fundamentalist.
I like ideas such as:

"Do the simplest thing that can possibly work, refactor and refine the
design later, if and when needed."

....and...

"Solve today's problems today and tomorrow's problems tomorrow."

Sadly, I don't find that this way of thinking works well for schema design,
where evolution and extensibility are often a very real concern and the
schema designer needs to predict (or divinate?) future requirements.

I find that predictive/proactive design and use of more powerful constructs
can lead to more extensible schemas. Unfortunately these schemas will
probably be also more difficult to adopt as they are more difficult to
understand and use.

-daniel


On 27 June 2012 11:14, Michael Kay <mike@saxonica.com> wrote:

>
>
> On 21/06/2012 17:44, Costello, Roger L. wrote:
>
>> Hi Folks,
>>
>> Below is a discussion of the rule of least power and how it applies to
>> XML Schema design. The rule of least power is very cool. Comments welcome.
>>  /Roger
>>
>>
>> The rule of least power says that given a choice of suitable ways to
>> implement something, choose the least powerful way.
>>
>>  While I can see the arguments, I have to say I am very uncomfortable
> with this as an architectural principle. A great deal of software design is
> concerned with building systems that have potential for change, and that
> means choosing technologies and designs that provide enough headroom to
> cope with future requirements as well as current requirements. I think this
> "rule" could be used to justify some really poor design decisions, for
> example using a text file for data interchange instead of using XML.
>
> Michael Kay
> Saxonica
>
>


-- 
____________________________________________________________
   Daniel Dui - daniel.dui@gmail.com - skype: danieldui