Bug 18973 - We need a way to write XPath expressions within elements
We need a way to write XPath expressions within elements
Status: CLOSED FIXED
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0
Working drafts
All All
: P2 normal
: ---
Assigned To: Michael Kay
Mailing list for public feedback on specs from XSL and XML Query WGs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-22 12:32 UTC by Eric van der Vlist
Modified: 2014-05-15 14:00 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric van der Vlist 2012-09-22 12:32:16 UTC
XPath is becoming more powerful with each new version and as syntax is getting more complex attributes become less and less adequate to write complex XPath expressions:

 * it is not possible to use CDATA sections to avoid escaping common characters such as "<".
 * many tools do not preserve white spaces (and indentation) within attributes.
 * XML comments cannot be embedded in attributes.

Being able to write XPath expressions within elements content would then be really handy for complex XPath expressions.

I can think of two options to achieve this.

The first one would be to generalize AVTs so that XPath expressions can be embedded within text nodes using curly brackets. Florent Georges mentioned something along these lines yesterday at the XML Summer School but I don't find the feature in the latest working draft and it seemed to be restricted to a very specific kind of usage anyway. 

The second option would be to define and xsl:select element that could be use anywhere where @select attributes are allowed in a transformation and would have exactly the same meaning and content (any @select attribute could be replaced by an xsl:select element with the exact same content and any xsl:select element could be replaced by a @select attribute (after having removed comments and PIs)):

<xsl:variable select="... long XPath expression..."/>

would be equivalent to

<xsl:variable>
  <xsl:select>... long XPath expression...</xsl:select>
</xsl:variable>

Being only syntactic sugar, this should be a rather minor modification but it would make our life much easier!

Would that make sense?

Thanks,

Eric
Comment 1 Michael Kay 2012-09-23 08:04:47 UTC
We've got an open discussion item in the working group called "text value templates" which addresses this area.

There's some debate about whether curlies in element content should mean xsl:value-of or xsl:copy-of.
Comment 2 Eric van der Vlist 2012-09-23 09:04:38 UTC
(In reply to comment #1)
> We've got an open discussion item in the working group called "text value
> templates" which addresses this area.

That's what Florent mentioned, but this seemed to be specific to specific XSLT instructions.

> There's some debate about whether curlies in element content should mean
> xsl:value-of or xsl:copy-of.

Yes. IMHO, we do need to be able to write XPath expressions within element content even when they return nodes.

An <xsl:select> element would be different: its semantic (and implementation) would be exactly the same as current @select attributes and could be used by the same XSLT instructions.

Eric
Comment 3 Michael Kay 2012-09-23 09:31:09 UTC
I guess xsl:select is addressing a slightly different (or overlapping) requirement. Unlike TVTs, it doesn't reduce verbosity (in fact, it increases the stylesheet size). It doesn't have the backwards compatibility issues of TVTs. But I think the benefits are less tangible. If escaping "<" is a problem, then it's quite likely that half the time the problem arises in "test" attributes rather than "select" attributes, and the proposal doesn't solve that. 

A different approach to the "<" problem would be to allow use of ﹤ and < (xFE64/xFF1C) as synonyms for < (x3C) in the XPath grammar; at the same time we could allow ≤ (x2264) for <=,  etc.≪
Comment 4 Michael Kay 2013-02-12 09:23:35 UTC
We have added "text value templates" which allow any text node in a sequence constructor to contain expressions in curly braces. The semantics are the same as AVTs, so the result is always a string (technically, a text node). We attempted a design in which the expressions in curly braces were not atomized, but it produced too many inconsistencies, with the whitespace handling depending on what kind of node you were constructing.

We recognize this is a partial solution to the requirement but we felt it was the cleanest design.