Re: XML vrs SGML tools [was Re: Capitalizing on HTML (was ...)]
At 11:18 AM 9/19/96 CDT, Paul Grosso wrote:
>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?
Just that all of the "SGML-heads" in the world (you and I) would jump all
over them when they don't implement RS/RE and all of the SHORTAG and OMITTAG
weirdness (as we should...conformance to half of a standard isn't really
conformance). And that's before we get into the REALLY obscure corners of
SGML. So implementing a full SGML parser DOES require the DTD, which slows
everything down (both because of the time to download it and the time to
> 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?
I would hope "not much." Except that all of the SGML estoeria would be
hidden from them.
>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).
>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.
Even the conversion from Word to XML would be qualititatively better than
the conversion from Word to HTML. XML would preserve as many of the Word
document's semantics as are present.
>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.