abstraction (was: re: re: Re: Feeler for SML (Simple Markup Language)
On 16 Nov 1999 rev-bob@g... wrote: > > Funny - I would have thought that it was because they [expletive deleted], rather than > > because they used abstraction. > And what [expletive deleted] about them? IMO, they [expletive deleted] 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 [expletive deleted] - 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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format