[
Lists Home |
Date Index |
Thread Index
]
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@redhat.com]
Sent: Tuesday, March 19, 2002 7:17 AM
To: Paul Prescod
Cc: xml-dev@lists.xml.org
Subject: Re: SV: [xml-dev] 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@redhat.com | 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>
|
