Re: [whatwg] Web Forms 2 Repetition Model?please reinstate on specification

Matthew Slyman, M.A. Computer Science (Camb)
-- 
Quoting Ian Hickson <ian@hixie.ch>:
>
> We took it out because it was just far too complicated a solution to solve
> far too narrow a set of use cases.
>
> However, there is a lot of ongoing work in this area of research,
> especially currently in the public-webapps@w3.org group. I encourage you
> to bring up the suggestion there. Unfortunately, coming up with a
> declarative solution whose cost-to-usefulness ratio is good enough has
> proven over the years to be a rather elusive goal.
>

I find this surprising. Unless of course you're trying to create a  
tool to do everything (in which case you're diving head-first down a  
rabbit-warren), or otherwise, have already tried that and decided it  
doesn't work, and therefore decided that it's not worth attempting a  
solution to any part of this problem.

Let's address another potential misconception at the same time. I  
recently dug up an old archive message from 2004/2005 in which some  
fellow was talking the repetition model down on the basis that  
"repetition would be programming and declarative models aren't meant  
to do programming" or something to that effect. Repetition isn't truly  
programming if it isn't Turing-complete. But I get the point, and I  
would NEVER ask for a declarative solution that would be  
Turing-complete.

Let's look at a case study or two:

===Chemical formulae===: These have had a repetition model for a long  
time now, which is very simple but very powerful. Like so:
Ca(OH)2  [subscript 2 - put superscript figures in for charge if you want.]
Nobody has a problem with this. It does the job and it's very  
powerful. Just powerful enough, yet not so "powerful" that you end up  
with 20 different ways to write the same chemical formula (the system  
is sufficiently restrictive to enforce a common system of notation).  
It strikes the balance perfectly, and forms a perfect demonstration of  
the relative advancement of chemistry as compared with many other  
sciences. The combination of power and simplicity in this system of  
chemical notation (which closely resembles the basic HTML5 "Repetition  
Model") enables the world of chemistry to get on with their real work  
without worrying too much about the art of notation, and enable  
chemists to find prior art easily.

===Linear equations===: A similar case could be made for these.  
They're a separate class of problems from the much larger set of  
problems that can be tackled with mathematics in general. You  
shouldn't put the folks that need real power and freedom in a  
strait-jacket by forcing them to work with a system designed for  
linear equations only. Likewise, you shouldn't burden and befuddle the  
novices and the folks that just need to get a quick linear equation  
job done, by forcing them to work with a generalised mathematical tool  
that they're just not trained to handle, and will never be confident  
using.

===Classes of problems===: For many problems, there is such a thing as  
"too much power". Let's please recognise that we're dealing with two  
distinct classes of problems here. There is a class of problems that  
requires a similar approach/solution to what we see in chemical  
notation (where one only requires a contiguous repetition of a block  
of HTML, which may or may not include repeatable subgroups), and  
another separate and much larger class of problems that requires the  
greater power available in a programming language. The correct  
solution for the former is a declarative solution like the basic HTML5  
Repetition Model. The correct solution for the latter is Javascript or  
something similar.

===CONCLUSIONS===: We need a declarative solution for HTML repetition,  
the same way Chemists need a declarative solution for repetition of  
chemical formulae.

Please reinstate the basic HTML5 Repetition Model. The system design  
as it stood just a few months ago was excellent in my opinion, and not  
at all in need of major revision if any.

-- 
Matthew Slyman, M.A. Computer Science (Camb)

Received on Sunday, 25 September 2011 13:18:04 UTC