Matthew Slyman, M.A. Computer Science (Camb)
--
Quoting Ian Hickson <i...@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)
