Subject: Programmable or declarative stylesheets? From: Paul Prescod <papresco@xxxxxxxxxxxxxxxxxxxxxxxxx> Date: Mon, 19 May 1997 08:57:28 -0400 |
James Clark wrote: > This is an interesting point. One solution might be for browsers to provide > a configurable timeout for processing each node (I seem to remember > PostScript printers have something like this). Don't browser vendors > already have basicallly the same problem with HTML scripting? Yes. But I think that they have to "solve" it separately for each language. I'm generally leary of schemes that send source code over the Internet. It always feels messy in several ways. Many of these reasons are vague and based more on my experience and observations than on any theoretical difference between programmable and declarative languages: The probability of an implementation bug in a full programming language seem much higher to me. It is harder to reason about the interaction of features when they can be more arbitrarily combined. Even though the languages are theoretically side effect free, like DSSSL, or secure, like Java, a bug in the implementation code can make them much more dangerous than handlers for non-executable data types. I mean even if you know about a bug in someone's HTML handling it is very hard to exploit that bug to DO something interesting. But if you can find a way to break the security on DSSSL or Java handling then you have a complete programming language at your disposal to try and exploit it. Implementations of declarative languages can be more optimized than implementations of full programming languages because the language implementor decides on how a particular feature is coded rather than the stylesheet "programmer". Bugs in fully programmable stylesheets are much more likely and are harder to recover from (though Jade is quite good at it!). Non-programmable stylesheet languages seem a little more "backwards compatible" in this sense: If you view a document that was created with XML and CSS (for instance) *without* CSS, or without some of the features the author used, the document structure is basically the same, but the style is missing. You can apply the style "mentally" or using another simple stylesheet language (e.g. one optimized for braille). But when the document's display depends on arbitrary transformations, the path from document source to reasonable display could be quite large. This is not a problem in a typical SGML environment where all of the software is controlled and works together, but on the Web I think that the document sent across the net should be trivially displayable. There is a tendency for systems with a built-in programming language to leave out functions because they can be implemented as part of the stylesheet language. For instance HTML doesn't have any kind of reasonable footnote or popup note element. But that feature can now be implemented in "JavaScript". So now the impetus for the declarative function is reduced. DSSSL is admirable in the wealth of functions it provides despite the fact that they can be created from procedure combinations, but being forced into a declarative box has a way of focussing thought which I believe to be healthy. I am willing to admit, though, that some things cannot be done in a strictly declarative style. I support the use of Java, for instance, for interactive widgets that could not be otherwise created. Can stylesheets fall on the declarative side of the fence if transformations are done on the server? Paul Prescod DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Denial of Service Attacks, James Clark | Thread | Re: Denial of Service Attacks, Gavin Nicol |
</DSSSL standard as PDF from TeX>, Sebastian Rahtz | Date | Re: Heresy? Re: DSSSL WWW Enhanceme, Alex Milowski |
Month |