OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: is that a fork in the road?

At 02:05 PM 3/2/01 -0600, Bullard, Claude L (Len) wrote:
>Right.  The point I want to make
>is that XML and these languages per
>se as "simplified" bits required that
>long complicated bit that came before
>to figure out which bits were simple,
>which 20 does what 80 of the work.

I hate to point this out, but you seem to have a vision of a world in which 
spec complexity is inescapable, recurring, and inevitable.  I fear you 
don't give communities credit for the potential to learn from the impact of 
past complexities, and expect every new spec to be as hopelessly 
intertwingled as SGML, CALS, and HyTime - _none_ of which qualify as a 
worthy role model for future spec development in my book.

Yes, we need experience to learn which 20% is useful.  We also need to 
foresight to realize that piling 200% on top of the 20% we just slimmed 
down to is probably not going to help much.

>Before we lament the complexity (We are whining!)
>or really sidetrack

I don't understand why you regard efforts to learn from XML's success - 
that doing less is doing more - as whining.

Of course, I tend to regard people who insist that long lists of features 
be piled into what once looked simple and usable as whiners myself, so 
maybe I shouldn't be critical.

Simon St.Laurent - Associate Editor, O'Reilly and Associates
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books