RE: [xsl] Normalize / Simplify HTML-Tables with row-span / col-span

[David Tolpin <dvd@xxxxxxxxxxxxxx>]

> Certainly, I don't think there is any justification for imposing
> restrictions on the user-visible language in order to make
> implementations faster in this area. It's very rarely good design to do
> that.

The justification is that SAXON 6 has a bug exactly in this place.
Building node-set is slow. Because SAXON 6 uses the same data structure
for node-set and RTF, building RTF is slow too, giving ten-fold difference
in performance with XT on some documents in cases which are difficult
to predict.

In general, exposing through the API or the language things which are
not trivial and which cannot be required to be implemented optimally IS
good design, and an evidence is a number of programming languages and
systems which are efficient and follow this design. C, Java (the language),
 Scheme, Unix, Openlook, Relax NG are some examples of it. 

On the other hand, systems which hide from the user things that can
supposedly be done efficiently, but the efficient way is not specified
or is not clear, suffer from this very issue and are failures in
the long run. Examples are Ada, C++, Common LISP, VMS (and Windows
NT, based on the same architecture as VMS), many Java libraries,
CDE, Motiff, XML Schema.

There is a third approach: when a formalism relies on a complex semantics,
but the semantics is described thoroughly. Examples are Haskell (lazy
evaluation) and Scheme (tail recursion). But this differs from what happens
with XSLT, since there is no description for computational semantics in XSLT.

David Tolpin
http://davidashen.net/

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list