Re: Capitalizing on HTML (was Re: equivalent power in SGML and XML)

> From Charles@SGMLsource.com  Tue Sep 17 17:43:18 1996
> On Tue, 17 Sep 96 09:10:36 CDT, Robert Streich <streich@slb.com> wrote:
> >If XML is to be anything more than just a stimulating mental exercise, it
> >has to be a relatively easy jump for any HTML author who isn't afraid to use
> >HoTMetaL, emacs, etc. to edit HTML. It's difficult enough to get most people
> >to make the leap away from display-oriented markup. If we add a lot of
> >restrictions or syntax oddities, we could make the jump downright undesirable.
> >
> I wasn't aware that converting HTML users was a requirement of XML. I thought
> the objective was a lean-and-mean dialect of SGML that would: 
>
> 1. reduce the size of web transmissions of SGML documents 

My apologies on this one. I didn't see it on the list of "design principles"
so I thought it was a non-issue especially with the trend in many of the
discussions towards increasing the amount of markup to make it easier to
write the parser.

Since this is a requirement that Jon validated in a later mail (I think
he was referring to this message), I'll have to change my opinion on a few
issues.

> 3. be easier to implement tools for because:
> a) only one (or a few) character sets are supported
> b) the instance can be parsed (but not validated) without reference to a  DTD
> c) attributes can be validated, parsed, and defaulted without reference to a
> _full_ DTD
> d)tools for full SGML can easily generate and accept XML without loss of EE-ESIS
> information

And I agree that these are all good things and worth pursuing. However, I
remain very skeptical that there will be a big surge of new tools. I
hope that one of the vendor-types will correct me if I'm wrong, but I'd
bet that the changes that we are discussing affect less than 1% of the
code base of the typical SGML system on the market today.

If the changes to the language have a significant effect on the authors,
then it really doesn't matter how simple it is to write a parser. Without
authors, there won't be anything for the parsers to parse. Resistance to
change has been the biggest impediment to SGML acceptance that I've faced.
If we make XML more difficult to author than SGML, it doesn't stand a chance.

> It would certainly be wonderful if XML won a host of HTML users to SGML, but
> that is a fringe benefit. Our real growth opportunity is winning more users to
> SGML because of the existence of XML. If we start confusing the requirements we
> run the risk of not satisfying any of them (as others have pointed out before on
> this list).

I think you might be missing my intent. I'm not concerned about winning over
generic HTML users or "Joe Homepage" as others have referred to them. I'm
concerned about *providing an easy path* for the thousands of HTML users we
have in my company. We have several hundred WWW servers on our net (nobody
really knows for sure how many). That's a lot of people typing HTML. It'd
be really great if I could offer them something that was easier to get
started with, i.e., didn't introduce too many new concepts, cheaper, and
got them on the track towards SGML. I was hoping that XML could fill that
need.


Robert Streich			streich@slb.com
Schlumberger			512-331-3318 (voice)
Austin Research			512-331-3760 (fax)

Received on Wednesday, 18 September 1996 19:46:45 UTC