RE: Is "simplicity" a useful architectural constraint?

I agree with Roy.  I find Java to be pretty useful and it has a rather large
set of specifications around it.  I also find reliable messaging systems to
be pretty useful, and they have fairly large specifications as well.

I would like to observe that the web has a variety of facets, each with it's
own trade-offs of simplicity vs complexity.  To pick one aspect, the W3C is
working on a variety of specifications that have modularity mechanisms.
XSLT, XQuery, XML Schema, XML, all have some form of inclusion/import
mechanism.  It makes sense for each "language" to define it's own modularity
mechanism that is tailored to it's needs. But pity the poor developer that
needs to use all of them at once - he/she has to learn 3,4,5 or more
syntaxes and characteristics.  Further each vocabulary has to implement it's
own code to do the "stitching" together.  So only big companies can actually
implement a piece of software that does XSLT/XQuery/XML Schema/DOM/etc.  It
is completely possible to debate both sides of whether many modularity
syntaxes or a smaller # should exist.

One approach that I like is to think about the customer of the specification
and how many of them you expect to use the spec.  Further, do the users have
to understand significant portions (the monolithicity factor) to do
something useful.   HTML was simple and still has a fairly simple subset so
millions of people can use it.  I still can't write an XML schema document
with refinement and facet constraints without referring to the primer, yet I
can easily write subclasses in Java.  These are examples of specs that have
different target audiences and audience sizes, imho.

A final point is that sometimes you just can't make the spec simple as the
task is just too complicated.

To me, the trade-off is really about picking the complexity in the the
audience size versus functionality chart that best meets the goals of the
spec.  Kind of like the innovation point on the chaos versus order chart.

Cheers,
Dave

> -----Original Message-----
> From: www-tag-request@w3.org
> [mailto:www-tag-request@w3.org]On Behalf Of
> Roy T. Fielding
> Sent: Wednesday, January 02, 2002 5:47 PM
> To: Jeff Lowery
> Cc: 'Duane Nickull'; 'Tim Bray'; www-tag@w3.org
> Subject: Re: Is "simplicity" a useful architectural constraint?
>
>
> There is no correspondence between good protocols and simple
> specification.
>
> There are some protocols that are simple to describe but, as a result,
> cause the number of interactions necessary to do anything via
> those protocols
> to be very complex.  There are other protocols that are
> difficult to describe
> due to the number of potential states, but are simple in
> practice because
> the state machine to implement them is relatively flat.
> There are many
> specifications that are simply incomplete, and other
> specifications that
> are long because the wrong formalism was chosen.  Likewise,
> many protocols
> have been designed with layers for "simplicity", only to find
> that those
> layers cause so much overhead, alignment, and fragmentation
> problems that
> an efficient implementation becomes hopelessly complex.
>
> I've never seen a good formal notation that was shorter than
> a specification
> without formalism.  One is not a substitute for the other.  I
> once wrote a
> 95 page Z specification of a boulevard stop -- the same
> protocol is described
> in two pages in the California driver's manual.  Likewise,
> formalisms are
> notoriously bad for describing the workarounds necessary to deal with
> poor implementations.
>
> Ignore the size of the specification.  What is important in
> an architecture
> is the complexity of an implementation and the complexity of
> its interactions
> with other components.
>
> ....Roy
>
>

Received on Thursday, 3 January 2002 01:13:58 UTC