[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: experts

  • From: "Bullard, Claude L (Len)" <clbullar@i...>
  • To: Justin Couch <justin@v...>
  • Date: Fri, 30 Mar 2001 09:36:35 -0600

funny company names
Yet it sat there in use for the last five years. 

Yes, the incompatibilities in the implementations 
were glaring, the vendors rivalries enormous, 
all true.  Yet it sat there in use for five 
years and the resistance to change has been 
incredible.  Why?

Partly a troll, but partly fact.  The pace 
of mucking with a spec makes it just as unendurable 
as the work left undone.  I also recall the 
end of the VRML project (much like XML) where a 
minimal victory was declared and everyone was 
told to go and implement the left-over 
parts away.  They tried that.  The event models 
are a problem but the simple obvious bits were 
the incompatible color models.  Interaction 
is important but in a rendering app, the 
consistency of appearance is critical.  So 
people hammered on that model.  Meanwhile, the 
vendors began to die off.   Experts went walkabout.

VRMLNextGen became a two encoding project.  
We had a language in which the original object 
model was tied directly to the syntax of the 
file format.  People rose up to defend the brackets 
when they should have been looking at the object 
model.  XML was declared to be the death knell 
because "everyone" knew a document model couldn't 
be used for the object model.  Few stopped to 
look at the infoSet and some blithely accepted 
that two encodings couldn't be harmful.  They 
locked horns on the syntax.  Experts told them, 
uhh, the object model first, brackets later. 
But hey, the W3C wanted pointy so pointy it was.

You are right about the lack of understanding 
for many of us.  It was a learning experience. 
But I also remember being told that HTML was 
the "shining moment of clarity" and all of that 
from those who designed the first object model. 
XML, "the evil from the east" and so on.   IOW, 
stooges on both sides of the aisle.  nyuk-nyuk-nyuk.

Competence: how high can you toss the balls when 
juggling?

Things that have multiple standard parents 
rarely stay simple or on track.   The only thing 
that kept VRML stable was the five year cycle for 
changes while all of the OTHER specs not yet standards 
got hacked into some semblance of stability.

On this point you are wrong:  the VRML spec group
was never closed.  It has always operated in the 
open.  Some people left [expletive deleted] off, that is true, 
and some returned for hire or for entertainment, but 
they never closed the doors.  It is the one promise 
kept.  Now, did they keep on remaking the same 
decisions?  no.  At certain points, they picked a 
direction with or without understanding it and 
went forward.  XML was a bear.  The DTD wasn't 
up to the modeling challenges, Schemas weren't 
done, XPath wasn't done.  The DOM event model 
wasn't done.   MPEG was trying to move it into their 
models complete with patented tech, some 
wanted to replumb XML (just a DOM 
away from being gay; SMLs funny), and on and 
on and on, collision after liaison, expert after 
standard.   And so it went.

Meanwhile, VRML97 sat there fat dumb and happy 
being used for five years.  God bless ISO.

Interoperability?  Heck, we'd just like to have 
the same capability as the original VRML97 still 
working, so we rely on the two vendors still standing 
extensions and all.  They are after all, experts. 

And they both use VRML97: fat, dumb, and happy.

We can't have cooperation, negotiation, interoperation, 
webbiness and so on without a certain reserve about 
what is possible.  Some call that minimalism, some 
just do the obvious bits and don't need a name or a 
religion for common sense.  OTOH, it is almost 
certain that the advanced bits won't get done or 
won't be interoperable when done.  

Complexity bites.  So is simplicity the solution?

Sort of.  It comes with its own ticket.  The truth about the web 
is that to have interoperability at scale, one becomes content with a 
certain mediocrity in the applications and incredibly 
wary of those that proffer simplistic solutions 
for what are known complex problems.  Daring to 
do less means being able to do less.   Trying to 
do more with less often means taking profit 
and turning it into customer bribes.  When that 
runs out, the customer becomes the patsy.

It becomes drug dealing in the webHood.

Last year, web businesses were giving away web services.  
This year, MP3.COM charges artists for the privilege of being 
paid for MP3.COM to use their songs, AT&T is charging 
for being paid for its services (that's right; we 
pay them to bill us unless we allow them direct access 
to our bank accounts and give up the ability to inspect 
bill prior to payment), and submarine patents are 
being welded to open technology.

Why does Microsoft dominate?  They don't care 
unless it ships a million copies.  They throw away 
the rest and if you count on an app on the scrap, 
you burn with the leftover DNA.  

It is the cost of lowering the cost.  

Scale is a key to the record business and the software 
business, but not the scale of application, 
the scale of sales.   Farmers need large orchards 
to make minimal profits off seasonal harvests. 
Otherwise, fruit costs what it costs to grow 
without migrant labor and heavy pesticides.

Organic tastes like industrial; it just rots faster.

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

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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.