Re: XML vrs SGML tools [was Re: Capitalizing on HTML (was ...)]

> >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?  
> 
> The barrier to entry for SGML is that it must be converted to HTML because
> browser writers won't support a language with a DTD. XML solves the browser
> writers' problem, which will also solve the end user problem (providing we
> don't overcomplicate XML in our obsession with ease of parsing).
> 

I disagree with this.  I don't think the DTD is the problem - after
all, they don't have a problem parsing HTML, and it's really much
easier to use SP for arbitrary DTDs than to write an HTML parser from
scratch.  I think the problem is more that SGML requires both a DTD
and a style sheet before data can be displayed.  XML will not totally
resolve this problem, but should help lighten the load.  

For HTML, the browser writer (really, the early browser writers, since
this is changing with the presence of real money) only needs to
display one document type one way (possibly with a few user set
parameters).  This can be hacked in a couple of weeks.  Now move to
SGML/XML, and even suppose we can parse it without a DTD.  How do you
display it?  There are no default display semantics for the elements
of the document and no algorithm to produce them without any domain
knowledge.  Therefore there must be a style sheet of some type for the
document, so the browser writer must support some style sheet
language.  Doing this may or may not be harder than just formatting
HTML, but it certainly opens several problems which no browser writer
can resolve alone - which style language (how long did it take the
SGML community to develop one) and what are the display
characteristics it should support.  

On the writer side, the writer only need learn HTML and can have a
fair idea of what the document will look like (esp. when there is only
one main browser available).  But with SGML/XML, the writer must both
find an appropriate doctype and an appropriate style sheet, or develop
them.  This can be, in and of itself, as difficult as developing HTML
and a browser from scratch.

Among other things, this indicates that there is no sense in pursuing
the "Joe Homepage" market.  Joe Homepage has a perfectly good
application, which serves his purposes well (this is not to say that I
don't also agree with Len's more economic-oriented argument).  People
who will use XML will do so because they have more complex needs than
showing baby pictures.

> >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.
> 
> >From my point of view, the problem the end user market perceives is that
> once they make an SGML document they must buy or write an expensive
> conversion program to display it on the Web. If we can win over the browser
> writers, we've solved that problem.
> 
The problem is that the lack of available/cheap SGML tools make the
barriers to entry too high.  Making it much easier to make good tools
will lower that barrier to where more people will make the effort.

Browsing - i.e., displaying info to a human, is only one particular
application of information.  It would be a big mistake to think that
that is the only one which counts for the Net.

Matthew Fuchs
matt@wdi.disney.com
http://galt.cs.nyu.edu/students/fuchs

I don't speak for Disney, and this message was probably forged, anyway.

Received on Friday, 20 September 1996 13:45:39 UTC