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 Carlisle <davidc@xxxxxxxxx>
Date: Wed, 18 Feb 2004 14:13:12 GMT
> and this is a partial quote,

True (although the list guidlines do say people shouldn't quote whole

> I am not discussing XSLT 1.0. There is no way to build node-set in XSLT 1.0.


> XSLT 1.0 + *:node-set, however, provides a clean way to get a node-set
> where it is needed.

It's bizarre. In years on this list I've never seen anyone have a good
word to say about the RTF restrictions, and I always assumed in all
implementations it was simply an artificial restriction. Not just java
implementations; msxml in early releases did not distinguish these
either, they only added the tests to stop your querying in to an RTF
variable as a conformance issue (I was one of the people that
complained to them. Even though I think RTF was a bad idea, the idea
that some processors do not enforce the restriction would be worse).

Now within the last couple of weeks or so, first Daniel Veillard and
now you say that there are implementation/efficiency concerns with
dropping this restriction. If you say so, I do not doubt you (I have
always avoided looking at the source code of any XSLT system).
I believe you, but I must say I'm surprised. an RTF looks, smells and feels
like a node set with a single document node, I'm surprised that you can
really build one in a manner that is so different from a node set
(again, I am not doubting you). 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?

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???

<xsl:variable name="x-of-some-weird-opaque-type">
<xsl:variable name="x-you-can-use"  select="node-set($x-of-some-weird-opaque-type)"/>

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?

> 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:-)

> For portability reasons it is often makes sense to just provide a chain
> of stylesheets wrapped by an external glue, such as Bourne shell, perl 
> or whatever else is available. There is more than one tool.

Yes, if it's really the entire document that is going through multiple
passes. I have several cases though where the basic document transform
can be done in one pass but where it would be really convenient to do a
multiple pass transformation on small fragments (of mathematics, normally)
which require some complex transform that's hard to specify in a single
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)



This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:

 XSL-List info and archive:

Current Thread