Lists Home |
Date Index |
- From: email@example.com
- To: firstname.lastname@example.org
- Date: 19 Nov 99 17:45:59 -0500
> > 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
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
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
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:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)