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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] s-expressions and XML was Re: [xml-dev] terra incog nita

[ Lists Home | Date Index | Thread Index ]

> -----Original Message-----
> From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
> Sent: Tuesday, December 18, 2001 7:27 AM
> To: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] s-expressions and XML was Re: [xml-dev] terra
> incog nita
> > -----Original Message-----
> > From: Jonathan Borden [mailto:jborden@mediaone.net]
> > Sent: Tuesday, December 18, 2001 9:49 AM
> > To: David Brownell; Joe English; xml-dev@lists.xml.org; Tim Bray
> > Subject: [xml-dev] s-expressions and XML was Re: [xml-dev] terra
> > incognita
> > 
> > There are many similarities between LISP and XSLT, excepting 
> > of course that XML et al. have been solidly backed by 
> commercial folk, at 
> > least that is the claim. Perhaps the differences are more to do with
> marketing than
> > technology.
> Richard P. Gabriel's Worse is Better essay
> (http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1
> .html see also
> http://www.dreamsongs.com/WorseIsBetter.html) is the classic 
> explanation of
> why LISP is a marginal technology today and Unix/C/DOS/Windows/etc. is
> everywhere.  Everyone should read it a couple of times a year ... or
> whenever the thought that doing the Right Thing will pay the 
> bills starts to
> infect one's consciousness.
> Here's "worse is better" in a nutshell ... see if you think 
> it fits in with
> XML's success so far.
> "The worse-is-better philosophy is only slightly different:
> Simplicity-the design must be simple, both in implementation 
> and interface.
> It is more important for the implementation to be simple than 
> the interface.
> Simplicity is the most important consideration in a design.
> Correctness-the design must be correct in all observable 
> aspects. It is
> slightly better to be simple than correct.
> Consistency-the design must not be overly inconsistent. 
> Consistency can be
> sacrificed for simplicity in some cases, but it is better to 
> drop those
> parts of the design that deal with less common circumstances than to
> introduce either implementational complexity or inconsistency.
> Completeness-the design must cover as many important situations as is
> practical. All reasonably expected cases should be covered. 
> Completeness can
> be sacrificed in favor of any other quality. In fact, 
> completeness must
> sacrificed whenever implementation simplicity is jeopardized. 
> Consistency
> can be sacrificed to achieve completeness if simplicity is retained;
> especially worthless is consistency of interface."
> Intriguingly, I sat near a member of the W3C Schema working 
> group on a plane
> a couple of years ago, and he was reading the Worse is Better essay
> (apparently it was "assigned reading" for the WG).  I wonder what they
> concluded from the assignment; it would appear that most recent W3C
> activities are the antithesis of Worse is Better.   
> Simplicity is being
> sacrificed for correctness and completeness, and specs are 
> held up for years
> while they try to sort out consistency.  This is obviously 
> the Right Thing
> to do, but does it take XML down the same road to oblivion that LISP
> traveled?  Time will tell ...
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS