[
Lists Home |
Date Index |
Thread Index
]
Hello Jeff,
Jeff said:
Similarly, adopting the STX streaming version of XSLT rather than real W3C
XSLT might make sense too, so that rendering can start as soon as the
stylesheet and enough data appears. If the idea is to build a new platform
(e.g. in Java) to support distros of domain-specific non-HTML XML browsers
that are not supported well by IDE frameworks or HTML browsers (which is
debatable), we don't need to be constrained to use W3C technology like XSD
or XSLT actually. If we use the same ingrediants as we had 10 years ago,
we will come up with the same cake.
Didier replies:
Jeff, the latest release was in 2004 and we are in 2006. From what I
understood, CML has already a Java interpreter translating CML into a 3D
representation. The main critic is that it takes a long time to be
downloaded into a browser. The facts are:
- there is a CML view written and Java, displaying a 3D view and able to
display CML documents. (ex:
http://jodi.tamu.edu/Articles/v05/i01/Murray-Rust/datument/mol2d3d.html)
- the critic is that it take a long time to download the applets. I noticed
that in the previous example, the applet wasn't packaged in such ways to be
signed and made available in the cached code. Having it cached in the client
machine would reduce tremendously the download time.
Therefore, I have now a question for Peter: Why the applet is not packaged
as a cacheable component. Both firefox and Microsoft support this feature. I
am not sure Opera and Safari support it. Is it because of Safari and Opera?
If yes, why not use an <iframe> element loading a small engine able to
recognize the different environments are let the browser load the cacheable
applet when available (Firefox and Mozilla - 96% of the market). And make it
loadable like it is right now for the remaining small fraction of the market
(4%). I have some trouble to see why this wasn't done when you are ready to
build from scratch a new solution? I am puzzled Peter ????
I did a small experiment with an applet I made for the fun of it. I packaged
it as a cacheable component for both mozilla and IE. The load time was
reduced tremendously. I wasn't able to reduce the load time of the
interpreter though, this is under the control of the VM provider (IBM or
Sun) and the plug-in provider (sun). So, is the time taken to load the
interpreter environment the issue?
I am trying to understand the real issues here.
Cheers
Didier PH Martin
|
