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
    SGML editor?

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.

paul

Received on Thursday, 19 September 1996 12:32:42 UTC