[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Content constructors and sequences


Subject: Re: [xsl] Content constructors and sequences
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Thu, 10 Jan 2002 16:43:40 +0000

Hi Kevin,

> Yes, more specifically as in the 1.0 RTF type. I misread the how
> copy-of will handle sequences of simple values in 2.0 so there will
> only be one text node with the concatination of the values and
> seperators. Not that I particularly think it has to be that way, but
> I guess it is consistent with how documents are normally constructed
> although at odds with what happen if you used individual value-of
> instructions on the sequence.

I don't think it's at odds with what happens if you use individual
value-of instructions. Say you had $foo containing:

  (1, 2, 3)

If you did:

  <xsl:copy-of select="$foo" />

you'd get a text node whose string value was "123".

If you did:

  <xsl:value-of select="$foo[1]" />
  <xsl:value-of select="$foo[2]" />
  <xsl:value-of select="$foo[3]" />

you'd also get a text node whose string value was "123" - (each
xsl:value-of creates a separate text node, but consecutive text nodes
are always combined into one in XSLT).

> This was what I missed in the original post. I hand't twigged you
> want this so you could process a sequence of original nodes later.
> To rephrase it in very basic 1.0 terms you want to use the syntax
> normally reserved for RTF creation to create a Nodeset.

Yes (and importantly a node set containing existing nodes rather than
new ones).

>> It would certainly be interesting to see a proposal that made these
>> two extensions to the the data model - added simple typed value
>> nodes and reference nodes. This would enable documents to hold
>> simple typed values and references to nodes from other documents,
>> which would mean XSLT could do the same "sequence manipulation" as
>> XPath has to now.
>
> This appears to me, a much more natural approach to the problem and
> what I was refereing to when I said,

Fair enough. I think we agree on the basic point (extending XSLT so
that it can generate sequences, rather than extending XPath with lots
of programming syntax). I think that our first hurdle is winning the
WG over on this principal - we can argue about how it's best to
achieve that later :)

So I'd suggest you post to xsl-editors@xxxxxx, with a brief
description or a full proposal or just an assertion that that's the
kind of thing you want to see. The more options we give the WG,
demonstrating that it's feasible to get XSLT to generate sequences,
the more likely we are to get over that first hurdle.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


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



Current Thread
Keywords