[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: SV: Tim Bray on "Which Technologies Matter?"
Parsing and formatting on the fly is exactly what HyBrick did, and it was distributed free. Plug-ins for both IE and Netscape were developed, although never distributed. This was non-optimized, demonstration code, and despite a substantial amount of processing overhead (which could have been eliminated had the product gone commercial), was nonetheless successful. HyBrick ran on SP and Jade; the excess overhead included DSSSL "architectural" processing and switching between the SGML and XML environments. The latter took place because the architectural forms for DSSSL were in SGML syntax, which, unlike XML, is case insensitive. Rather than change the syntax of the DSSSL architectural forms to XML, a processing context switch was achieved when rendering an XML document. The context switch was carried out by using SGML catalogs to direct processing to the proper directory, where the appropriate SGML declaration was used to specify the required syntax. So the DSSSL architectural forms and stylesheet DTD were processed as SGML, while a document in XML syntax was processed as XML. HyBrick, by the way, allowed the user to choose between multiple DSSSL stylesheets declared in the document. For the record, the major problem found with SP had nothing to do with SGML processing overhead. Rather, when James Clark wrote SP, he wrote his own (non-Winsock) socket classes. Re-working James' code to work with proxy servers did not prove feasible. This of course would have been a serious defect in a commercial product, and was a significant factor in the decision to terminate the project. --Ralph -----Original Message----- From: Daniel Veillard [mailto:veillard@r...] Sent: Tuesday, March 19, 2002 7:17 AM To: Paul Prescod Cc: xml-dev@l... Subject: Re: SV: Tim Bray on "Which Technologies Matter?" On Tue, Mar 19, 2002 at 06:17:21AM -0800, Paul Prescod wrote: > Daniel Veillard wrote: > > > >... > > > > There is also like 50 times more implementations. It also takes 50 times > > less CPU to process (a bit stretched but between jade and libxslt rendering > > of the same DocBook document there is a quantum gap, and yes this matters !) > > There are way too many variables for you to declare that that has > anything to do with SGML versus XML parsing. One poor algorithm in > either DSSSL or XSLT could drag performance down that much. Possibly, but the end result is there, some bug or performances problems get fixed, others don't. I was arguing against a statement that XML was pure hype and less sophisticated. It may be hype but there is more implementations to choose from, it may be less sophisticated but in practice things which were looking impossible with the previous toolchain becomes possible like formatting on the fly upon user request. One could probably had done that on SGML too, but not with free software apparently. The sophistication trade-off have a serious impact in that area. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@r... | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ ----------------------------------------------------------------- The xml-dev list is sponsored by XML.org <http://www.xml.org>, an initiative of OASIS <http://www.oasis-open.org> The list archives are at http://lists.xml.org/archives/xml-dev/ To subscribe or unsubscribe from this list use the subscription manager: <http://lists.xml.org/ob/adm.pl>
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|