XML vrs SGML tools [was Re: Capitalizing on HTML (was ...)]
> From: Charles@sgmlsource.com (Charles F. Goldfarb)
> . . .
> Bob has raised another interesting point. I assumed (item #2 in my
> corrected summary, below) that encouraging easy tool-building is a
> major goal of XML. Bob says it will never happen, that SGML tools and
> HTML tools are the only ones we'll ever see. Is he right? We should
> decide ASAP if that goal is unrealistic, as it has a major effect on
> the language design. (Indeed, it is virtually the only reason to have
> XML, if I understand things correctly.)
> There is a corollary to that point as well: what is our assumption
> regarding whether XML creation will be done with SGML and XML tools, or
> with ordinary text editors? To put it another way, is it ok for XML to
> be inconvenient to create "by hand" as long as it is reasonably
> possible to do so? (Jon?)
> . . .
Sorry, this is likely to be a bit of a side track from our technical
discussions, so if Jon opts to quash further follow up on this, I won't
be offended, but I was trying to do some big picture thinking again,
and again I've gotten myself confused. Here's where I've got myself
stuck--where am I wrong:
1. A key reason for designing the XML "language/meta-language" is to
encourage more/better/cheaper tools. We seem to be saying that
we are not designing XML to directly benefit end users: we're not
giving them more capabilities, we're not making it easier to enter
by hand, and making it somehow simpler to "understand/explain" is
*not* an end-user benefit [how many HTML users "understand" HTML
as oppose to just use a certain tool until they like the results].
Of course, we believe the end user will benefit from XML as a result
of all the more/better/cheaper tools, but our design goal is really
aimed at the tool builders. [I may be exaggerating the point a bit
here, but only a little, I think.]
2. So let's look at tools. There are viewers and browsers who would
like to be able to display files without reference to a DTD. Aren't
there a lot out there like that already? If someone today wrote
documents using a DTD will no declared content, what's to stop a
browser tool from processing the document without a DTD now? Or
more to the point, how will the life of the end user of a viewer be
different with XML than with SGML? Now to editors--it's still not
clear we have consensus on whether XML editors will need (the logical
equivalent of) some DTD, but whether they do or not, what will look
different to an end user sitting in front of an XML editor versus an
3. We're trying to create XML so as to encourage more/better/cheaper
tools. So my question is: what's wrong with current tools--from
an end user's point of view--that won't be wrong with XML tools?
What is the barrier to entry to SGML from an end user's point of view
and how does XML propose to address it?
4. Let's look at the "more/better/cheaper tools" argument. 90% of all
documents in the world today are written using MS Word. We don't
need more tools if there are no problems with the ones that exist.
Okay, cheaper. That's a bit of a red herring. If any SGML tool
vendor thought it could make more money by reducing its prices, it
would trip over it's own feet trying to do that faster than the next
guy. And there are an increasing number of public domain or very
cheap tools on the market. What makes us think that more cheaper
tools will really qualitatively increase the use of SGML/XML?
5. So we're left with "better." End users want a tool that is "better"
than the SGML tools available today. Now this is something worth
investigating. What is wrong with the tools of today, and what would
be better? This can't have an easy answer, or someone would have
created such a tool and taken over the market. And what about XML
will enable tools to be created that are not only so much better than
the SGML tools we have now but that are better than the SGML tools we
could end up with if we put as much effort into the SGML tools that
we expect to be put into XML tools?
I'm finding myself confused at our attempt to make a language that is
easier to understand by the implementors and therefore easier to build
the tools for end users to use. Cars are not simpler to understand than
they were half a century ago and certainly not simpler to build, but in
many ways they are easier, more comfortable, and more fun to drive. If
we want to increase the use of SGML or something SGML-like, we have to
make the tools more fun to drive. I'm failing to see how fiddling the
language really addresses the problem the end user market perceives.