Re: [xml-dev] XPath 2.0 - how much of XQuery should it include?

Hi Mike,

>> Of course there's not full composability, but then neither
>> design gives you that (or at least not as I understand it). 
>> In the current design, there are the duplications:
>> 
>>    - xsl:choose   vs. if
>>    - xsl:for-each vs. for
>>    - xsl:variable vs. range variables
>>    - xsl:sort     vs. sort()
>> 
>> xsl:item would eliminate the requirement for the last two of 
>> these duplications. I'm not sure what duplications it would 
>> add in their place?
>
> You are assuming we would be able to remove range variables from
> XPath, which is by no means a necessary consequence of adding
> xsl:item.

Yes, you're right. I am assuming that. If you don't remove range
variables, I agree that xsl:item isn't worthwhile. The point of
suggesting xsl:item was to enable you to remove range variables from
XPath 2.0 and thus reduce XPath 2.0's one of the parts of the
complexity of XPath 2.0 that people are complaining most about, whilst
retaining the user's ability to do joins.

Otherwise, xsl:item offers the benefits of allowing people to use
variables, xsl:number and to apply templates to nodes to generate
sequences. But I don't think these benefits are worthwhile in the face
of the additional duplication. If the choice is range variables with
xsl:item or range variables without xsl:item, then the latter is the
one to choose. I just don't think those should be the only choices
you're considering.

> We would probably be able to ditch sort(), though I would be
> reluctant to see it go: the construct
>
> <xsl:variable name="sorted-list">
>   <xsl:for-each select="x">
>     <xsl:sort select="."/>
>     <xsl:item select="."/>
>   </xsl:for-each>
> </xsl:variable>
>
> seems very clumsy compared with
>
> <xsl:variable name="sorted-list" select="sort(x)"/>

Certainly, but then I believe that it's very rare that you want to
make a sorted list *just for the sake of it*. The only time that I can
think of people doing that at the moment (naturally through the
longhand as above) is so that they can then use
preceding/following-sibling axes to create groups. But grouping is
supported in other ways, the preceding/following-sibling axes won't
work within sequences anyway, and the ability to create named sort
specifications means that if you *did* want to sort the same sequence
in the same way twice you could do so easily. So I don't think this is
such a vital operation.

Naturally it's all guesswork and we won't know until we start trying
to use it, but it's a lot easier to add something to a language later
on than it is to remove it.

> We would end up with a new duplication in the area of sequence
> construction, because XPath would certainly not be viable without
> the (x,y,z) construct.

Well, if you view tree construction as a restricted form of sequence
construction, then there's already that duplication.

> And the more I think about using <xsl:for-each> and <xsl:choose> to
> do sequence construction, the more messy it seems. For example, what
> does the following mean:
>
> <xsl:variable name="x" type="sequence">
>   <xsl:item select="1"/>
>   <xsl:value-of select="2"/>
>   <xsl:value-of select="3"/>
> </xsl:variable>
>
> Do we really want this to create a sequence consisting of one
> integer and two text nodes?

Considering that sequences are flat, and that people will use them to
create the equivalent of multi-dimensional arrays by assigning
different meanings to items in different positions, I'd say yes, you
probably do want to allow a mixture of atomic values and result nodes
within a sequence. Also XQuery allows this, I believe, so it would be
closer to XQuery semantics to do so.

Then the question is about whether to combine the two text nodes
generated by the xsl:value-ofs. I'd say that you should adapt the XSLT
rule you already have concerning text nodes. At the moment, it reads:

 "The resulting text node is added to the result of the containing
  content constructor. When the resulting content is added to a result
  tree, adjacent text nodes in the result tree are automatically
  merged."

You could make it:

 "The resulting text node is added to the result of the containing
  sequence constructor. When the resulting sequence is used, adjacent
  text nodes in the sequence are automatically merged."

in which case you would have a sequence of one integer and one text
node.

If you don't want to allow mixed sequences, then you're going to need
to put a constraint to say so into XPath anyway. You could always say:

 "If a sequence contains a mixture of atomic values and nodes then
  the atomic values are automatically converted into text nodes with
  the same string value. Adjacent text nodes are then merged."

> And consider:
>
> <xsl:template name="x">
> <xsl:value-of select="first-name"/>
> <xsl:text> </xsl:text>
> <xsl:value-of select="last-name"/>
> </xsl:template>
>
> <xsl:variable name="y" type="sequence">
> <xsl:call-template name="y"/>
> </xsl:variable>
>
> How many items are there in the sequence $y?

The variable $y holds the sequence that's constructed by the template
x. From the above, templates generate sequences of new nodes, and when
sequences of new nodes are constructed, adjacent text nodes are
combined to give the finished article. So $y holds a single text node.

Cheers,

Jeni

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

Received on Thursday, 16 May 2002 05:28:59 UTC