Feeler for SML (Simple Markup Language)

[rev-bob at gotc.com]

> > Whoa there!  This is starting to remind me of some of the flamewars on
> > comp.lang.perl.misc over whether it's reasonable to expect a programmer to
> > RTFM!  If a particular wireless protocol really does need to be usable by
> > script kiddies [1], then the solution, to the extent that one is possible,
> > is to hide all the details in an application-specific API.
> 
> I guess what bothers me a bit about this whole discussion is the implicit
> assumption that it's somehow *bad* to use abstraction to hide the details;

I suppose I'd have to go with "dangerous" or "hazardous" - not necessarily "bad".  A 
conscientious programmer can use such dangerous things to his advantage, but a novice 
can easily use them as an excuse to become brain-dead.  Considering recent history, I 
have to refer you to the horde of "WYSIWYG" HTML editors on the market - editors 
which try to insulate novices from the code.  If these applications were a little bit 
different in their focus - say, ditching the WYSIWYG myth and generating good code - 
then they could serve a good purpose.  As things are, though, I cannot consider those 
applications anything but *bad*...precisely because of their level of abstraction.

> that it's somehow a mark of weakness to want to be able to do:
> 
>  $doc = new XML::Document($url);
>  $doc->transform($stylesheet, $ENV{'HTTP_USER_AGENT'});
>  print $doc;
>  # or whatever

If you know what you're doing, shortcuts aren't bad at all.  If your tools are trustworthy 
(unlike the aforementioned website-in-a-box tools), they can be valuable.  However, 
recent experience has taught me that the people most likely to produce Web-targeted 
tools with a high degree of abstraction are aiming those tools at precisely those people 
who shouldn't be using them.  It's kinda like handing a stick of dynamite and a lighter to 
a second-grader on the grounds that he doesn't know enough to make the explosives for 
himself.

> It's been almost two years since I was part of this list, and it's odd to 
> come back to it only to find the same endless discussions of whether or
> not XML should be easy. Of course it should. It doesn't harm anyone if the
> tools are abstracted to the point of usability, does it?

Power requires discipline.  If you're not disciplined enough to learn at least something 
about XML, maybe you shouldn't be using it.  Once you know where the pitfalls are and 
why certain things are bad ideas, then you can start building your own shortcuts - but 
getting them handed to you is just asking for trouble.

I'm not saying that all XML should be handcoded; quite the contrary.  I'm just trying to 
point out that while a power tool can be a great boon to a carpenter who knows his 
trade, buying a power tool doesn't make you a carpenter...and IMO, we should not 
encourage the mass distribution of power tools to novices.  We've seen what hacksaw 
surgery has done to HTML coding; hopefully, we can learn from that with XML.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.com


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)