Re: declarative expressons in WF2

On Mar 25, 2007, at 22:16, Dave Raggett wrote:

> On Sun, 25 Mar 2007, Anne van Kesteren wrote:
>> Doesn't help an implementor much. It seems you still haven't  
>> addressed the original concern various people expressed either on  
>> this mailing list or #html-wg.
> How so?
> We all know that it is impractical to analyse turing complete code,  
> and browsers wisely don't try to do so. If your scripts don't  
> behave as you expect, it is generally up to you as the programmer  
> to sort it out.

Browsers need to be interoperable when the input is non-conforming.  
For example, if the expressions have side effects, the side effects  
should guaranteed to happen under the same conditions and in the same  
order in different browsers.

> For the simplest case authors wouldn't need to write functions so  
> that problem wouldn't arise. Any functions that the editor provides  
> would have been written by experts and subject to testing to ensure
> that these functions abide by the rules.

But on the Web, browsers need to deal with the case when the  
functions do not abide by the rules. And they need to deal with those  
cases interoperably to prevent lock-in to the implementation details  
of a particular browser.

> You might say "What's wrong with event handlers?. Everyone in the  
> HTML WG is very comfortable with writing scripts for event  
> handlers, so what's the problem?"
> Well we have a duty of care to the rest of the population who don't  
> know and don't care about scripting.

I think it has not been established that "the rest of the population"  
can do declarative programming when they can't do imperative. Many  
people who have education in the field work with the imperative model  
more comfortably and only put up with declarative programming if  
there are some special benefits like automatic parallelization to be  
had. Why would the uneducated in the field find the easiness of the  
programming models to be in the reverse order compared to the educated?

> If we ignore that duty then the market will make a correction. HTML  
> will be sidelined as a delivery format and won't be an editing format.

In the case of e.g. bibliographies, HTML can be the editing format  
and the delivery format but the two aren't the same instance.  
Instead, running a bibliography generator on the authoring side is  

> In IRC you suggested that editors could recognize the scripts that  
> they generated. That's true, but leads to the undesirable situation  
> where you can only edit a document if it was created by that editor.

Since HTML has to serve the Web-wide array of delivery cases, it  
cannot encode profound semantics for all cases. There will inevitably  
be cases where the authoring format needs to have use case-specific  
data for editing that arbitrary HTML editors won't understand on a  
profound round-trippable level.

Henri Sivonen

Received on Sunday, 25 March 2007 22:02:13 UTC