Re: Sample Question

Anyone who really doesn't care about this thread, 
hit delete now.  I'll move it to CTS, but because 
that is a land where it is all too easy to get 
caught up in HTML IS HOLY debates, I thought 
it best to start here.

W. Eliot Kimber wrote:
> 
> What about this alternative:
> 
> <P>Your IP address is <SERVER>write(request.ip)</SERVER>
> <SERVER>write("&lt;p>Last time your were " + client.oldname + ".")</SERVER>
> 
> An addition of 3 characters.  The escaping could easily be provided by the
> sort of 10-line Perl script XML was specifically designed to enable the
> writing of, assuming that script understood the semantics of the Server
> element.

Good answer. That gets the dweeb in the back off the floor.
 
> Because we understand that the lexical parse occurs *before* the semantic
> parse.  But not in HTML processing.  I don't get it.

Bad answer.  No one will have a clue outside the few hackers in the 
room, and if they are HTML/Perl hackers, this all looks like more work.

Anyway, I suspect if we go back to the original HTML archives, we'll
find
some performance questions mixed in with 
some religious positions.  They do it that way because tag scanning  
is faster and surer than parsing for syntax based on a DTD that you 
might not have.  They do it to only connect once for a page and 
to move it without requiring a stateful protocol.  They do it 
to keep the packets small.  They do it because it works and 
is fast to build and design on a list community where the 
majority of contributors are not twenty-year hypermedia veterans.
They could do it because our governments paid for it and gave 
away the software, something few in our industry could afford.

Now they do it because they can't afford to undo it and many of 
our members do it right along with them because it is profitable.
Me too.

> The risk taken was investing in a delivery language designed too quickly by
> people who's only apparent goal was the shortest path to the quickest
> solution. 

What risk?  They got fabulously wealthy and are getting moreso everyday
while surrouding the customer's information in a very "tender" trap.

> If the world was fair, I could say they deserve what they get,
> which is a pile of hacked crap, but the world's not fair, so we do have to
> be sensitive to these people.  But that doesn't mean we have to accomodate
> every half-baked hack that comes out of Mountain View or Redmond or
> Cambridge or wherever.

No we don't.  We have to show that for equivalent functionality they 
get an easier system to manage and maintain.  For superior
functionality, they
get only slightly higher cost.  We have to show we learned our lesson,
"we" the 
community that sells high-priced word processors and once upon a time
charged 
$100,000 for parsers and $50,000 for hypertext that wasn't even in the 
same league as a free browser is today.

Cheap/free software is what we are up against.  We won't get rich doing
this.

> It means we have to carefully weigh the relative costs against XML's stated
> design goals and target audience, with as much thought as possible to
> future.  XML, like SGML, has a responsibility to the long-term interests of
> its users. Propogating bad hacks is usually not in those interests, even if
> it costs short-term pain.  Hard cases make bad law and entrenched hacks
> make bad standards.
> 
> XML is lower-cost SGML.  That doesn't mean it's necessarily pain-free SGML.
>  Doing the right thing often hurts ("Come to the Dark Side....it is
> your...Destiny").

Uh huh.  Tell them it is the *right* thing and that hall will
empty faster than a bookshop in tel aviv during a riot.  Tell them 
it's the smart thing and prove that in terms of their own problems, 
and you will make a sale.

They don't know it's a hack.  We can't tell them that.  Do we have to?
No, tell them the things about XML that work, tell them that mixing 
scripting into a markup file is maintenance-suicide.  

Tell that they should be able to separate the tasks of programming and
authoring 
as easily as they separate the tasks of drawing and writing.  Sure, 
some can do both, and some can do both well, but it isn't a high 
percentage.  They can't afford to pay programmers to write and 
writers to program, so that level of indirection David loves so is 
something advantageous to a business, not a moral position.

Tell them that when the platform dies, one has to 
move the information to another platform.  Remember that JavaScript 
is soon to be a standard, so don't tell them it is proprietary.
Show them examples of XML applications (eg. P. Murray-Rust's CML).

Take a Visual Basic 4 app and show them how they cannot now 
easily get information out (the text widget is rtf).  Show them 
they can take the same VB4 objects and one extra widget for 
XML, and they CAN get the information out.

Show what an EDI file is like right now and how much easier it would
be if they could move these as XML and use the SAME TREE editor 
to modify it.  Show them how a well-constructed set of tools 
can be used over and over again with each application getting 
better search and retrieval, data mining, and knowledge 
accretion by relationships that can form organically and 
be remembered by the system.

We can't tell them that the browsers and heroes they have bought 
into have feet of clay.  They think that is sore grapes from 
the losers, and as you told me in Seattle, "history is 
written by the winners".  

The media is NEVER wrong.  We can't tell them they've been 
had.  It is the same as telling them they are stupid when 
they know full well they have a running intranet hooked 
to a world wide Internet back at the shop for the first 
time after YEARS of unfulfilled promises from US.

XML fulfills the promise of SGML.  Tell them that, 
but it will be better to show them.  "Rough Consensus 
and RUNNING code.."  Learn from the guys who beat us.
But the code must be better than theirs/ours.

len

Received on Thursday, 30 January 1997 18:17:42 UTC