- From: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>
- Date: Thu, 19 Sep 1996 21:33:19 -0400
- To: paul@arbortext.com (Paul Grosso), w3c-sgml-wg@w3.org
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 parse it). > 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? 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. Paul Prescod
Received on Thursday, 19 September 1996 21:38:34 UTC