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

Subject: Re: [xsl] Normalize / Simplify HTML-Tables with row-span / col-span
From: David Tolpin <dvd@xxxxxxxxxxxxxx>
Date: Wed, 18 Feb 2004 19:06:34 +0400 (AMT)
> It's not as if you can linearise the RTF
> as it is built: namespace fixup, and possibly output indenting mean
> you have to have some notion of tree structure in there, and if it's a
> tree why shouldn't you be able to query into its structure?

In the simplest case, consider the difference between a list and an array.

A list is easy to append to and to traverse, an array is easy to address
but hard to append to (very raw analogy, I know, but still -- and it is 
what happens inside the processors, by the way).

A list could be used for RTF, an array for node-set. I do not insist
that it is how it should be done; but different roles of these two things
suggest different underlying structures. If I were implementing XSLT,
I'd consider the option of using different structures.

It is possible that I do not see something obvious. But please explain.

> I chose not to use node-set in my example, but if node-set() was brought
> in from the extension namespace and made a core function, are you really
> saying this is clean???

I don't know. Either a core function, or an attribute, or a different
syntax; but for me joining RTF and node-set in the same notion is
wrong.  I see danger. I would not do anything similar in my code
(that is, C|Java|Perl). If I need structures for different purposes,
I build different structures and reuse parts when it makes sense;
I learned the hard way not to build a structure that covers all
cases just for the sake of generality.

> How on earth would we be supposed to explain this language feature from a
> declarative point of view, without going in to implementation
> strategies for an XSLT compiler?

How on earth would we be supposed to explain that a particular language
feature 'should not be used' because of the fact that some implementations
are inefficient. And they are not required to be efficient in any particular
sense (that is, nowhere it is said that adding a node to the node-set must
be O(n) at most). And these arguments are not rootless -- many,if not most,
current implementations of XSLT 1.0 have performance and conformance problems
caused by the use of node-set where RTF is required.

> > The question is not whether to have a way to build a node-set or not,
> > but whether to have an explicit way to build a node-set, or to do it
> > always when an RTF is needed.
> Point taken. (which means that my message wasn't really fair as a reply
> to your message, but I'm sure you will survive:-)

I will :-). I don't think my reasoning will affect XSLT 2.0. But if there is
a theoretical chance to get XSLT 1.5, which is smaller than XSLT 1.0 with
extensions and cleaner than XSLT 1.0 without, then I would vote for it.

 apply-templates pass. Snatching up the result of the first pass into a
> variable in the template for the math element and re-applying a second
> batch of templates is a lot more natural than having to do a second pass
> over the whole document (with an identity transform on all the non-math
> bits) (athough of course you could do this with a node-set function
> which is your preferred alternative)

Yes. And here is another thing to consider. XSLT is being developed in
a way which will eventually allow it to read mail. If there were a plumbing
facility between XSLT and other tools, that would make my life easier.

David Tolpin

 XSL-List info and archive:

Current Thread