Re: Factual error was Re: Brainstorming: Best of all Worlds

On Mar 22, 2007, at 10:51 PM, Cameron McCormack wrote:

>
> Ian Hickson:
>>>> [halting problem]
>
> Dave Raggett:
>>> You are incorrect on this point. Please re-read the XForms  
>>> Transitional
>>> draft spec as I have clarified the wording based upon how my
>>> implementation works, and it should be noted that this has been  
>>> tested
>>> on a much wider range of browsers than Web Forms 2.0 has at this  
>>> point
>>> in time.
>
> Ian Hickson:
>> The new spec doesn't change the UA requirements, so you still (as far
>> as I can tell) require UAs to do static analysis of turing  
>> complete code,
>> which, here, reduces to the halting problem. (All you've done is  
>> made such
>> cases non-conforming, but that doesn't affect the UA at all.)
>
> Static analysis of programs doesn’t correspond to solving the halting
> problem, depending on what sort of analysis you need to do.  If one of
> the conditions for a calculate attribute is that its expression  
> needs to
> halt, then yes, that’s obviously a problem.  From my reading, the  
> static
> analysis that’s required by XForms Transitional is just the dependency
> analysis, which should always be possible.  Whether it comes up with
> useful dependencies without resorting to evaluating some of the
> expressions during the analysis is another matter though…

Evaluating expressions during analysis would mean you can't guarantee  
your static analysis will terminate, so the analysis would indeed not  
be Turing-decidable.

>
>> There are other problems, too, such as how to handle fields whose  
>> exact
>> lists of dependencies themselves depend on other field, e.g. because
>> the calculate="" field does something like:
>>
>>    calculate="document.forms[0][document.forms[0].field.value] + 1"
>
> …so with this example (or with
>
>   document.forms[0][document.forms[0].field.value].value + 1
>
> which I think is what you meant), if you allow limited evaluation  
> of the
> expression during analysis (rendering it therefore not truly static),
> the dependencies will be:
>
>   document
>   document.forms
>   document.forms[0]
>   document.forms[0].field
>   document.forms[0].field.value
>   document.forms[0][document.forms[0].field.value]
>   document.forms[0][document.forms[0].field.value].value

I don't think this corresponds to dependencies in the sense of XForms  
transitional, since you can't turn this into a list of form elements  
whose values you depend on. And consider how much worse things get if  
the user code uses eval().

> If any of these values change, then the form field with the calculate
> attribute on it needs to be recomputed.
>
> Static analysis wouldn’t allow the implementation to determine the
>
>   document.forms[0][document.forms[0].field.value]
>
> dependency, since it depends on whatever the current value of the
> ‘field’ field is.  That’d mean it has to watch all form fields in form
> number 0.  If the calculate attribute is in that same form, then that
> just introduced a cycle into the dependency graph.

Failing on everything that's impossible to statically analyze would  
certainly be one possible approach.

> Ian Hickson:
>>>> In the case of declarative calculations it is also not clear how
>>>> the feature could be made to degrade gracefully without breaking
>>>> full implementations.
>
> That’s true.  From IRC earlier, discussing a simple use case of
> automatic “order totals” in forms:
>
> <heycam> i think such things would be easier with things like
>   calculate=""
> <heycam> (if calculate="" were done properly)
> <heycam> but (and this is the big "but" that is going to cover much of
>   the discussion in this group, i think), it's the backwards
>   compatibility / fallback issue that is troublesome for such  
> proposals
> <heycam> if you need to write script to fall back when there's no
>   support for calculate="", then you may as well forget writing the
>   calculate="" in the first place

You skipped Ian's remarks that calculate="" might not even be  
suitable to real-world examples of an order form.

> (Oh and by “if calculate="" were done properly” above I mean not using
> arbitrary JavaScript.  When I was working on CSVG [1] (IIRC Dave  
> saw me
> and my poster on it at WWW2004) I decided on XPath as the expression
> syntax.  In the end, I think that was wrong–not because I have  
> anything
> particular against XPath, since it’s not bad for selecting things from
> XML documents, but because the syntax got clunky with the custom
> functions that fetched SVG-specific information from elements.   
> What was
> better about XPath than arbitrary JS though was the fact that it was
> much easier to analyse for dependencies.  I think a subset of JS  
> syntax
> would be good for XForms Transitional: that way you can leverage both
> the implementation of the JS engine and authors’ knowledge of JS, but
> constrain expressions so that they can’t have any nasties in them.)

A JS subset could lead to a sensible design, but it would amount to  
inventing a new language. Constraining expressions would also mean  
you still need the DOM events for the cases where you want to do  
something more than a simple constraint or calculation, such as  
checking other documents on the page, contacting a server via  
XMLHttpRequest, etc.

In any case, it would be nice to hear a proposal that is tight enough  
to actually work, although I think the feature of declarative  
constraints still needs to be checked against actual use cases on the  
web.

Regards,
Maciej

Received on Friday, 23 March 2007 06:21:10 UTC