Altova Mailing List Archives


Re: [xml-dev] Tim Bray on "Which Technologies Matter?"

From: Tim Bray <tbray@----------.--->
To: xml-dev@-----.---.---
Date: 3/18/2002 7:48:00 AM
Well er....

1. Those slides are a minimal skeleton designed to hold up an
    hour or so of verbiage.  Having said that, they're in a public
    place with my name on them so I guess I have to say whether I stand
    behind them or not.
2. I stand behind them.
3. I guess someone should expand them into a real essay with flesh
    between the bones.
4. The audience is a mainstream tech-conference audience - it's assumed
    that from their point of view a "successful" technology is one that
    shows up in their shop in mainstream applications.  Per that
    definition, SQL succeeded, OODBC not.  Java yes Ada no.  XML yes
    SGML no.  Et cetera.
5. The real point is that a bunch of things that ought to be predictors
    for technology success (thus defined) don't work very well.
6. I claim that hitting an 80/20 point is a strong predictor of
    success (positive and also negative in that technologies that don't
    hit it usually don't succeed), that there are a few less strong
    predictors (happy programmers, good early implementations, technical
    elegance), and that military backing is a weakish negative
    indicators.
7. For the weaker predictors, I acknowledge counterexamples.  I can't
    think of one, either positive or negative, for the 80/20 criterion.
8. As regards 4GLs, that's probably my fuzziest test case.  Someone
    pointed out correctly that the really commercially important
    outcome is VB.  But anyone who lived through the 4GL hype in the 80s
    (it basically amounted to "do away with programmers, and if you
    can't, do away with 'if' statements") tends to look back with a very
    jaundiced eye... and the Web seems to be giving poor old VB a tough
    time.
9. Simon suggested that XML was informed by HTML as much as by SGML.
    Don't think so; XML is a very pure SGML subset and I honestly can't
    think of any design components that came out of HTML.  (Out of the
    *Web*,  sure, e.g. compulsory URIs for all external references).
10. Several people have hurt feelings over my suggestion that SGML was
     not successful.  Perhaps my opinion is influenced by having on
     several occasions had to meet the payroll of a struggling SGML
     company out of my own pocket.  SGML "mattered" in the same sense
     that Robert Johnson and the Velvet Underground matter to popular
     music, but nobody bought their records and 99% of the programming
     profession ignored SGML.  Being important or mattering is not
     equivalent to success in the sense that trade-conference audiences
     think of it.
11. I've never heard a generalization about "SGML is better for X,
     XML for Y" that holds much water.  The most significant technical
     difference is that for SGML the rules say you have to read and
     believe the schema provided by the sender.  Given that a lot
     of successful SGML apps cheerfully broke that rule it's hard to
     lend it too much weight.

OK?  -Tim

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.