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: ZDNet Schema article,and hiding complexity within user-friendlyproducts



The point is complexity is a perception.  Given 
any point of view, and level of detail, one 
can simplify or complexify.  The language is 
precise and for that reason, obscure unless 
one is well-trained.  Madeleine Sparks and 
Charles Goldfarb both made me face up to 
the differences of audiences for given technical 
resources.    Simon is in the business of 
explaining this stuff.  I also live on the 
kindness of xml.com.  Otherwise, I have to 
put down the RFP, go to the spec, read slowly 
and very carefully rather than work some nicely 
put together examples from the xml.com authors.

If a good GUI hides a complex process, is that 
a bad thing?  If it hides unnecessary complexity, 
it isn't the fault of the GUI.

We should strive to simplify but should we 
do that at the cost of precision?  There isn't 
a single answer that satisfies.  There is only 
a goal which informs local process.

Len
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: C. M. Sperberg-McQueen [mailto:cmsmcq@acm.org]
Sent: Tuesday, April 24, 2001 6:31 PM
To: Bullard, Claude L (Len)
Cc: Gavin Thomas Nicol; xml-dev
Subject: RE: ZDNet Schema article,and hiding complexity within
user-friend lyproducts


At 2001-04-24 14:51, Bullard, Claude L \(Len\) wrote:
>Or that stuff like this is scary reading on the face of it...
>
>"A precise formulation of this constraint can also be offered in terms of
>operations on finite-state automaton: ...
>More money for Simon StL in his next book if he can condense that
>down to something understandable.  That really will be hiding the
>complexity.

Er, guys -- this is not more complex than the rules we all know and
love to hate from ISO 8879 or the XML spec.  It's just a bit more
brutally honest about the specifics.  (ISO 8879 describes the rule
fully but eccentrically, in ways that have to be translated painfully
into FSA terms for people who think in FSA terms, and the XML spec
just waves its hands and says "you know what we mean, right?")

-C. M. Sperberg-McQueen
  W3C