- From: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>
- Date: Mon, 11 Nov 1996 03:08:37 -0500
- To: cbullard@HiWAAY.net
- Cc: W3C-SGML-WG@w3.org
At 11:20 PM 11/10/96 -0600, Len Bullard wrote: >What is currently done and what can be done are different. I am not convinced. You can't just wire SP into a browser front-end and get "SGML on the Web". It requires too much meta-data. SGML wasn't designed for this environment, and it doesn't "fit". To get the performance we need, we have to have a mechanism for signalling empty elements that does not involve downloading the whole DTD. >> Although it would not be ideal, an XML that allows a simple, obvious >> transform from SGML is MUCH preferable to the current situation. I see a >> requirement to transform into XML as an inconvenience but not a show-stopper. > >No. Nor do I. I just see a slightly more awkward ugly system. In that case, we don't have to have a heated discussion of the issue, because one way or another, the show goes on. >I see >the same arguments being presented to defend HTML compatibility >that are used to defend SGML incompatibility. I see nonsense, and >pure and simple also-rans taking advantage of this situation. I don't know what you mean by this. >I don't like it, but I don't vote. But the name of the project >was SGML On The Web. When Connoly wrote to me about it, and >Jon asked me to join, that is what it was called. Yes, I've >read the statements as published. But if this is not to be >SGML On The Web, those are false colors and this project has >been misrepresented to the SGML community to gain from it >a credibility it does not merit. I can't say that any plainer. As far as I know, nobody is proposing any version of XML which is not SGML. What is being proposed is encoding of new semantics within SGML compatible syntax, which will require a post process to transform from the SGML produced by most SGML tools to the SGML subset that is XML. It is still SGML. Ever since I have been involved in SGML, proponents of it have used the term "SGML" to mean "generic markup." When they (and I) describe the benefits of SGML, they almost always describe it in terms of the benefits of generic markup. So even if XML was an SGML-incompatible generic markup language, W3C would be using _our_ loose terminology to describe their new technology. But nobody is proposing that. >> SGML 97 and XML have different legacy problems. The ERB wants some subset of >> XML documents to be compatible with EXISTING BROWSERS. That seems like a >> politically smart move to me. > >Whose browsers, Paul? NS and MS? There aren't many viable players >left for HTML. Guess what? MS votes but contributes nothing >to this list. Let Paoli defend >his browser, not you, not the rest of you. Microsoft or Netscape. >Their voices aren't even heard on this list. MS justs votes. >Nice job if you can get it. If they want to defend their >*existing browsers*, let them contribute to the discussion. >Are they above that? I dunno. I don't care. When it is in my best interest I will champion the causes of big, stupid, nasty corporations. As you'll see in my tagline, I like to encourage people to use Esso/Exxon or Texaco, because they are the lesser of x evils. Microsoft and Netscape are the cable companies. We have the content. We must conform to their content guidelines (no frontal nudity or undistinguished empty elements!) if we want wide viewership. If we don't want wide viewership, then we can just use our VCR (Panorama). >Politics, not technology? It seems that compatibility with >the existing base of SGML tools for SGML On The Web has a voice >here too? Am I wrong? I think the SGML community at large >should think about this. I think they should be very aware >that a self-appointed group of people under the banner of the >W3C is deciding whether web browsers from NS or MS are more >important than a decade of effort of standards-based tool >development and millions of dollars of existing information >for systems whose importance are a bit more invested than >What's On My Tube This Nanosecond. No, Paul, I am losing >patience with this argument. If you believe that full-blown SGML on the Web is feasible on today's network, we can continue to work towards that goal. Standards compliance is important, and I believe in it. But generic markup is important too -- more important, in my hierarchy. Otherwise why not standardize troff back in 1986? I want to make the generic markup Mass available to the laity. If that means translating it out of Latin, and losing a certain connection to the past, then so be it. It looks like the "translation" is going to be relatively trivial (and, perhaps, non existant). >> Could a parser-implementor comment on the extra difficulty imposed by the >> "don't worry, be smart" solution? How hard is it? > >It isn't. I don't think that is the issue. I think it is. Nobody wants to introduce incompatibility with existing tools as a joke. My understanding is that fast, easy recognition of empty elements is the ONLY reason for this new empty-element syntax. What do you think _is_ the issue? >> SGML on the Web seems to be a non-starter for small to medium sized >> companies/departments and individuals of all sizes. > >Bullshit. Pure and simple Bullshit. Anyone out there tried? >It depends on the simplification assumptions one makes and >the stylesheet. Have you tried? No. Yes. SoftQuad tried. We tried at the University of Waterloo. In the end, we decided to ship ESIS over the web. Panorama also requires a normalization process, and STILL requires the DTD. You posit that a satisfactory product can be built using today's network and today's processors without changing the output of SGML tools. I do not believe it. I could be wrong. Even if it is possible, that wouldn't make generic markup browsers ubiquitous, which is my personal goal in this endeavour. >> Even for big companies, >> I think that it is probably misleading to call the current (or near future) >> state of affairs "SGML on the Web". Panorama documents are not accessible to >> the majority of Web surfers, and SGML-transformed-to-HTML isn't really SGML >> anymore. If you are comfortable converting to HTML, you will be even more >> comfortable converting to XML (or XHTML, in the short term). > >I don't want to convert anything I don't have to. > >There is no fixing HTML. NS and MS own HTML. It's spoilt goods. >XML is still just a proposal. If NS and MS reject it, and the >SGML community choose another, ISO-originated choice, XML dies. If NS and MS reject XML and ISO releases a competitor, then we have gambled and lost, but lost only our time (which will SURELY be recycled into the ISO work anyhow). On the other hand, if NS and MS embrace XML, then we have transformed the world's largest information system into a generic markup based system. SGML-tool output can go through a trivial transform instead of an expensive one. We can publish our documents without information loss to the ordinary people who use the Web (as opposed to the "SGML community"). People with thousands, instead of tens of thousands of dollars can publish generic markup to this same massive readership. Users might start to demand generic markup capabilities in word processors and "Web editors." We can "ramp up" our style sheets from CSS to DSSSL-O to full DSSSL. We can deliver the "help files" for our products in generic markup. SGML databases can be served on the Web through a trivial CGI script. "A Generic Markup Browser on Every Desktop" I consider this a gamble with a million dollar prize and a 50/50 chance of winning. And I suspect that most members of the SGML community (which, IMO, is represented on the ERB) will be happy to take money from our new citizens and do a good deed at the same time. Paul Prescod --- Boycott Shell Oil worldwide! http://www.web.apc.org/embargo/shell.htm "Shell is here on trial and it is as well that it is represented by counsel said to be holding a watching brief."..."The ecological war that the Company has waged in the Delta will be called to question sooner than later." -Ken Saro-Wiwa to the tribunal that later executed him. http://www.goldmanprize.org/goldman/ken.html
Received on Monday, 11 November 1996 03:06:59 UTC