xml-dev - re: Re: History

[rev-bob@gotc.com]

> > But [TBL] didn't choose SGML. He saw some SGML documents and borrowed
> > some of the look of it. I am sure that he would not claim that he
> > understood SGML at the time.
> 
> Sebastian has beautifully illustrated my point from a previous post.  Many
> (most, I'll bet) HTML writers looked at HTML pages and "borrowed the look"
> of them - that's how they got started.  And it worked for them.

It works to a degree, sure.  If you want to do anything fancy with it, though, there's no 
better way than to learn the spec and go with it.  There are faster ways, and there are 
sloppier ways, but I argue that there is no *better* way.

When I first decided I wanted to make a web page, I picked up HTML For Dummies 
and went through it.  It gave me a basic idea of how things fit together; how HTML 
worked as a language.  (As it turns out, some of that information was wrong - but I 
learned that later.  One key goof involved TITLE and a matching H1 element, but that's 
off the topic.)  When I actually got down to the process of making that page, I whipped 
out my talismanic legal pad and did a literal markup job - I wrote what I wanted the first 
page to say, then indicated where I wanted to add links to later pages.  When I got home, 
I keyed that in and got working on it.  Yes, looking at source code was a big part of that 
process, especially when it came to using JavaScript...but when it came time to strike out 
on my own and start creating effects instead of simply aping what I could find elsewhere, 
the only way to do that was by getting a reference and using it.

Looking at source is a good way to get your feet wet; in fact, I may wind up scouting 
some DHTML source in the near future to get an idea of how I want to proceed with 
that.  The point is, it's a starting point...and that's all it should be.

> XML is pretty much the same way, and it works too.  But you can't do C++, or
> SGML, that way, for example.  You can't do everything this way that XML is
> capable of either, but most people don't need to do everything.  Simplifying XML
> (or really its use) will help to maintain the incredibly fast start it has had.
> We shouldn't lose the simplicity in the name of the more complex uses, just
> add optional layers.  This does seem to be the way things are going (schemas
> and xslt being layered on top of xml, for example).

In other words, we should simplify XML so a larger number of clueless people can 
misuse it more easily?

IMO, we already have an XML dialect for that audience.  It's called XHTML, and while 
it's not final yet, it really isn't too far off from "real" HTML...and yet, it gets people to 
notice things like well-formedness and strict syntax.  Frankly, I think the XHTML effort 
is as far as the "simplification" movement needs to go; if someone can't even be bothered 
to figure that dialect out, they probably can't be bothered to make a decent page in the 
first place.

Yes, I know that sounds really elitist of me - that may be because it IS elitist.  Probably 
comes from seeing too many "this is my cat's poetry" and "here's a list of Doom II cheat 
codes" pages.  I appreciate HTML being easy to learn, and I'm glad there are people out 
there who use this as an entry point, but I also see a lot of bad code out there.  With 
HTML being as simple as it is, I have to wonder about the intellectual capacity of people 
who get it badly wrong.  I'm sure they're good at something, but HTML ain't it - and 
oversimplifying XML in the name of attracting those people strikes me as analagous to 
saying that motorcycles should come with permanent training wheels because some 
people have bad balance.  If you have bad balance, use a car - because a motorcycle is 
the wrong choice for you.

Let's let the intellectually lazy people stick with HTML, where they can use FrontPage et 
al. to their hearts' content.  XML offers a prime opportunity to raise the bar a bit.  Yes, 
the full scope of XML is daunting - that's why you don't tackle it all right away.  Get it 
working a little at a time, work up gradually to a fully functional knowledge of the 
language.  If you don't want to use external entities because you don't grok 'em, fine - 
don't use them.  You don't need a special version of the language to put that constraint 
on you.

To close this out, here's an open question to all the "SML" supporters here.  Is there any 
part of what you want from SML that you could *NOT* get from writing a different 
form of documentation for XML?  (By which I mean, say you want no external entities, 
so you don't document them.)  What I'm getting at is that it may not be the spec itself 
that is of concern, but rather the documentation for that spec.  One person has said that 
by taking all the DTD stuff out of the XML spec, it was a lot easier to read.  Perhaps all 
this really means is that the DTD stuff could be moved to another part of the docs - it's 
still there if you want to get into it, but you don't feel the need to master it just to get 
your feet wet.  If the problem is the docs, write a simpler version and post it...but don't 
blame the language for having complex documentation.



 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@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@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)