Guiding principles

["Eve L. Maler" <eve.maler@east.sun.com>]

At our first F2F meeting, our major goal will be to finish developing the 
requirements that will shape our design work.  I'd like us to spend some 
time thinking about what overall principles should guide our selection of 
requirements and design choices.  We can bat this around in email, discuss 
it a bit at the 20 Feb telecon, and then begin our work on 2 March by 
deciding these principles before diving into the requirements.

Here's my thinking on what makes a good set of principles: They shouldn't 
really be measurable, like requirements are (having more than 5-10 
principles is probably a sign that they're too specific!).  Rather, they 
should be fairly broad and evocative, and should give clear expression to 
strong preferences (even if sometimes they're in conflict; we may want to 
force-rank them for this reason).  Ideally we should have a limited kind of 
"traceability" from requirements and design choices back to principles, in 
that we should be able to use them to defend decisions when necessary.

Hal Lockhart pointed me to the IETF's attempt at such a thing -- RFC 1958, 
Architectural Principles of the Internet:

   ftp://ftp.isi.edu/in-notes/rfc1958.txt

There are also XML's design goals:

   http://www.w3.org/TR/REC-xml#sec-origin-goals

Perhaps there are other sources for good ideas too.  Here are the ones I 
like best so far, using these sources and things that have been discussed 
among us:

- Ur-principle (statement of scope and purpose): Define an XML framework 
for exchanging authentication and authorization information.

- If there are several ways of doing the same thing, choose 
one.  (Simplifies implementations and increases the chances of 
interoperability.)

- Keep optional features to the absolute minimum, ideally zero.  (This is 
almost, but not quite, the same thing as the previous.)

- Keep it simple. When in doubt during design, choose the simplest solution.

- Modularity is good. If you can keep things separate, do so.

- Solve common problems with well-understood solutions rather than solving 
lofty problems with theoretical solutions.  "The only thing more dangerous 
than generalizing from only one example is to generalize from *no* examples!"

- Require multiple interoperable instances of running code before 
standardization.

Now I'll step back and let others weigh in...

	Eve
--
Eve Maler                                          +1 781 442 3190
Sun Microsystems XML Technology Center    eve.maler @ east.sun.com