Producer and Consumer, the economy of unAPI

While I am riding the bus to Los Alamos, I ponder a problem which annoys me for a while in unAPI design and was debating still now: what's simple, and not too simple in unAPI?

I think I got something and eager to write down, again this is an economy issue. There are two parties in most web applications: producers and consumers; when producers are potentially quite outnumber consumer, you want to make producer as simple as possible, and leave most complexity to consumer, because consumer benefits more ($$$) from this cycle and therefore is willing to afford the complexity.

Maybe this is too abstract, but it may make sense if we think about several examples. (a) In the web, there are so many nasty HTML pages, but we are all happily living with it, because the consumer (browser, search engine, etc) takes extra efforts of making sense of these pages. (b) In the RSS/Atom world, there are several standards and many more nasty pages but news aggregators happily support them all.

So maybe I have the answer now. In unAPI we want to make the producer as simple as possible, we don't want to burden them for heavy error processing or schema validation -- so we can claim they are wrong here and there, no! it must be extremely easier and nasty errors are tolerated (such as HTML or RSS), content is king here; it's up to the consumer to make order from chaos.