abstraction (was: re: re: Re: Feeler for SML (Simple Markup Language)

[Steven Champeon]

On 16 Nov 1999 rev-bob at gotc.com wrote:
> > Funny - I would have thought that it was because they sucked, rather than
> > because they used abstraction.
 
> And what sucks about them?  IMO, they suck because they take abstraction
> too far without being trustworthy in doing so.  Not only is the sort of
> abstraction faulty (HTML as WYSIWYG?!?!?), but the produced code is
> faulty...and yet, the products are advertised as trustworthy substitutes
> for knowledge.  This is why they suck - faulty abstraction, pure and
> simple.

Ah, I see. So what you're saying is that if something may have negative
consequences as a result of its misuse, it should be denied to the
uninitiated. OK, that's fine. Let's start with the Bible.

> > Let's not ditch Java because it makes use of design patterns, or DNS
> > because it allows for a nice, friendly, hierarchical model for four-
> > byte long integers. Similarly, let's not expect every user of XML to
> > have to think about every tag in their tagset when they really want
> > to be *authoring* a document.

> Now, call me strange, but I don't see the correlation here.  I'm saying
> abstraction **CAN BE** bad (and hence **IS** dangerous - danger being
> that which can lead to bad results) because it encourages people to
> think lazily.  Perhaps my point will be clearer if I explain that I'm
> all in favor of automation - but if you don't know what you're
> automating, you will get into trouble.  Heck, my site is automated to
> the hilt - and yet, I control every last byte that comes out.  See the
> distinction?

No.

> > Stupid abstraction is bad. That doesn't mean abstraction itself is
> > bad. and it doesn't mean that you don't want to know about the guts,
> > just that there's a time and a place for everything.
>
> I never said abstraction was inherently bad - I called it dangerous
> because, if not used carefully, it can become bad.  Explosives can be
> used intelligently to collapse a building with no collateral damage, or
> they can be used stupidly.  It is this very versatility, coupled with
> their ease of use, which makes them dangerous.  I'm looking forward to
> www.xml for precisely one reason: XML is strict and unambiguous, in
> stark contrast to HTML's looseness and ambiguity.  This looseness has
> allowed a lot of bad tools to pop up, gaining popularity despite the
> hideous code they generate - and why?  Because they're abstract enough
> that any idiot can use 'em.

HTML began life as an SGML DTD, with such limited use that it rapidly
evolved into something else, ditching the rigor in the process. One might
argue that it was flawed from the beginning due to its use of formatting
elements like <B>, but you can't blame the failure of HTML (which, in one
sense, is its enormous success) on its looseness and ambiguity. If we've
learned anything from HTML, I should hope that it would be that HTML wasn't
abstracted /enough/, that the so-called "looseness and ambiguity" is more
the result of people writing non-validating browsers.

In fact, seeing as how the Web took off long before there was a decent
widely available HTML editor, you could blame the failure on handcoders
alone. So let's stop hiding behind these poorly-abstracted editors you
keep harping about.

Seeing as how XML is fundamentally about validation and/or
well-formedness, and that the structure has been carefull kept from the
presentation, and the logic kept separate from both, there shouldn't be
any trouble, now, should there?

> > That's silly. Recent experience has also shown me that poorly designed Web
> > tools exist at all levels, not just the "Let FrontPage be Your Webmaster"
> > level.
 
> True enough - but my point is that FP et al. are sufficiently
> ill-designed to churn out bad code, yet sufficiently well-designed to be
> easy to use.  This is a deadly combination, in that it leads to a
> proliferation of bad code through the ease of use allowed by a high
> level of abstraction that insulates the trusting user from knowing he's
> producing bad code.  There are poorly designed tools in every field; is
> that an excuse to promote them in a new field?

Again, you've introduced a straw man - I'm not promoting poorly designed
tools, I'm arguing for the utility of well-abstracted tools. This, over and
against your insistence that XML should remain in the hands of those who
arbitrarily limit their abstractions out of some misguided fear.

One could argue that the problem with FrontPage and its kind is less a
problem of poor HTML output and more of introducing a page-centric view
into what should be performed using higher-level abstractions (e.g.,
"sitelets", "areas", "chunks"). 

> > Your metaphor is misleading and dangerous. A more appropriate metaphor
> > might go like this:
> > 
> >   "It's like a child learning how to talk before he knows the
> >    rules of proper grammar."
> >
> > In the former, you're assuming responsibility for someone's lack of
> > knowledge but your response is to hide it from them for their own
> > safety. In the latter, the responsibility is still there, but now
> > it's up to you to demonstrate good grammar and in so doing, ensure
> > that the child learns well.

> The problem with your new metaphor is that, if the child doesn't know
> proper grammar, he cannot communicate well - and thus, there is a
> built-in impetus for him to learn how to communicate correctly. 

*laugh*

You've missed the point altogether. Children learn to talk before they
/ever/ have the rules of grammar explained to them. And if you think that
there is no difference between communicating "effectively" and "correctly",
you've obviously never heard a baby cry.

> With FrontPage et al., there is no such impetus; the "child" never knows
> he is being misunderstood. 

Similarly so for handcoders, and people who only test their markup in 
their own favorite browser, etc.

> A critical level of feedback is missing there; this is the dangerous
> part.  I've seen this happen with HTML; I have no desire to see XML
> tread the same path. 

You sincerely believe that the Web was ruined by lazy people with WYSIWYG
editors, don't you? Go back and ask the Mosaic folks if their browser had
a validating SGML parser. Ask the Netscape developers if there was ever
a validating SGML parser in their browser. Ask Microsoft. Ask anyone, but
you'll hear the same thing over and over. None of the SGML-aware browsers
(Amaya, Arena, etc.) ever got enough of an install base, or were difficult
to use, or introduced ridiculous changes in the interface metaphor so as
to effectively ruin their chances. Ask the Hotmetal people how well it
was received when they hardcoded HTML DTDs into the editor.

HTML was not ruined by a lack of feedback, it was a natural evolution from
<B> to <IMG> to <TABLE>s used as layout containers. Netscape's attempt to
break with HTML's flaws by introducing a multimedia-influenced LAYER DOM
was called all manner of evil names, but it was at least true to the Web
that HTML started, while trying to fix some of the worse flaws.

> Let the novices play with HTML; it's already broken.  Why should we make
> it easy for them to break XML as well?

How will making something easy to use, while not surrendering its inherent
robustness, make it easy for novices to break it? If anything, it seems to
me that it will ensure it's success.

I find it extremely difficult to say the same about requiring everyone to
hand-code their own start- and end-tag handlers, thereby virtually
guaranteeing that one of the following happens:

 1) people who aren't programmers will stay away from XML
 2) bad programmers will screw up XML worse than they did HTML

Steve
-- 
business: http://hesketh.com ...custom medium- to large-scale web sites
the book: http://dhtml-guis.com  ...Building Dynamic HTML GUIs from IDG
punditry: http://a.jaundicedeye.com       ...negative forces have value
personal: http://hesketh.com/schampeo/  ...info, projects, random stuff


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)