Re: acceptance of XML

Lou Burnard wrote:
> 
> >I don't suggest the user base is unimportant.  The habits of HTML are
> >very much the habits of SGML authors in most cases.  So, trying to
> 
> most cases of SGML authors or most cases of habit? Either way I vigorously
> dissent. HTML habits are for the most part inimical and in opposition to most
> habits of anyone worthy the name of "SGML author". HTML focuses attention on
> how to render fragmentary pieces of digital data. It actively discourages
> attention on how to organize such fragments into higher level structures,
> oither than by the tiresome procedure of tying everything together with
> explicit links.

Ok, but I consider the latter design, not authoring.  So, a hair split
because 
in every other way, I agree.  It is the typing habits I am referring to
that 
lead to exacerbated debates on white space.  We keep trying to preserve 
the ability to put whitespace anywhere, and that complicates things.  I 
would prefer to explicitly mark up everything, disallow inclusions and 
exclusions, etc.  Quoting pseudo-elements isn't something I care for
because
folks will blow that one.  Don't believe they don't hack the ASCII and 
that an editor or application can handle all of that.  That won't
happen.
But they can be taught pretty easily to use markup more rigorously and 
that habit is just as bad in many SGML applications as it is in HTML.
 
> As far as XML is concerned, I think the way to sell it is to demonstrate (with
> some real software) that (a) you can do everything you can already do with HTML
> with XML (b) you can do a whole lot more besides with XML

I completely agree.

> The way *not* to sell it, is to focus on (a) to the exclusion of (b).

Agreed.  We have to show them why that "whole lot more" is worth doing 
and accept that for some, it isn't.  The CTS debate on Affording SGML 
is in some ways, a "drop the religious mystical fascination with 
SGML information" and get to the benefits vs the cost per application. 
Too often, I think, we have oversold the difficulty and undersold 
the smarts of the customer.  I seem to be in the minority on this one
because it is a sea change even for me, but requring the customer 
to rethink and redo every part of their pubs process to accomodate 
SGML quirks, or the preferences of the consultant, is the way 
to keep SGML out of the mainstream.  Adjusting the expectations of 
both to the realities of the tools and the existing processes,
then offering a path to evolve as needed is more realistic.  This 
is the problem with IETMs vs ETMs and Java vs HTML:  we can't afford 
programmers as authors.  Further, they tend to be lousy at it.
SGML is the middle ground, the interface.  That is the benefit.

Don't shock the monkey, and stay off the peels.

Anyway, I think the list moderator will justifiably curtail this 
thread soon.  We should debate these issues off list, or back on 
CTS.  I apologize for moving the rumble onto a focused working group.
 
> Pardon me for stating the obvious, but I don't think I'm the only one on this
> list guilty of that personality disorder.

We all be weird, Lou.

len

Received on Thursday, 3 October 1996 10:20:47 UTC