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

RE: XML in .NET - more than just SOAP? (RANT)

• From: "Bullard, Claude L (Len)" <clbullar@i...>
• To: xml-dev@l...
• Date: Mon, 31 Jul 2000 13:31:42 -0500

I spent most of the morning teaching XML to two 
reasonably well-trained programmers.  At the end, they 
said, "Just show us something simple so we can get 
on with our little project."  If they couldn't 
"get it" in two hours, what good was it?  The fact 
that it took four to six years of university and 
some number of years of a job to get them to the 
place that OneMoreSliver(A tiny thin wafer of knowledge) 
would make them explode keeps them unable to apply what 
they do know.

Ring a bell out there?  That AHA moment takes time.
But this is simple XML right?  If it parses, it's 
good, right?  If it is well-formed, it is 
good, right?  Sure.  SMOP.

<rant>It is really hard to explain XML past 
tag pairs to people who have so much stuff 
in their heads that there is not room for 
the abstractions that underlie the implementations 
of XML systems.  Ok, so much for basing our 
marketing on myths like the Desperate PERL 
Hacker, because the reality is the first 
audience is a lot of jaded, self-satisfied, 
"we don't need no stinking tags" C++/Java/etc. 
programmers.  They have their *little* projects 
and not much time to learn anything new, and 
they aren't convinced they need to.  HTML is 
simple, right?  XML is cool, right?  What is 
that infoSet thing and why do I need one?

Well, there is that well-formed thing.... SMOP?

The second problem is the 
crappy little document flung to the floor 
was only the flavoring and not the substance. 
We are so good at buying the simplifying 
assumptions we can't get past the "name 
is not the thing" issues that make up 
the substance, and yet until one understands 
the abstractions, the temptation to go 
"write some code to do the little simple 
thing" overwhelms the certainty of having
to rip that code out six months later, 
rearchitect and punch a gaping bleeding 
hole in a tight schedule. 

This is what the 10,000 'softies are dealing with. 

The name is not the thing.  The moon in the water 
is not the moon.  One moon, not two.  Tag pairs 
aren't objects.  APIs need abstract data sets and 
the DTD and the schema don't provide them.  The 
DOM needed them first but the cart got ahead of the 
horse and yes the code got out of the lab.  

We wanted it, right?  We couldn't wait, right? 
We were told, "the state of the implementations 
is not a consideration in the final form of the 
specification" and we agreed to that, right?
 
Put this conceptual chasm beside the mountain 
of legacy code that MUST be supported or there 
won't be ANY rice in the bowls NEXT week, and you can 
see why the problems of XML Goodness happen.   
It is hard.  It really is.  It is hardest of all 
for the *to the metal* programmers who have 
to code to an unfinished specification or 
one they don't have time to read.   

Overhyped press releases: if folks want to get 
into that topic, let's dig up the old HTML WG 
archives and see who was smarter than whom when. 
It's a Fugs song whose lyrics should not be 
fully quoted here:  "River of S**T, roll 'on".  

It is the parser's job to be Draconian.  People 
can patch.  (Thanks, Simon, thanks Dave Raggett.)</rant>

Len (out of patience for the moment)

http://fly.hiwaay.net/~cbullard/lensongs.ram

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

• Prev by Date: XML in Office 200X
• Next by Date: RE: XML in O2K (was "XML in .NET")
• Previous by thread: XML in Office 200X
• Next by thread: RE: dynamic loading of Handlers
• Index(es):
  • Date
  • Thread