-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[XQuery] String Value Templates #58
Comments
This reminds me of the existing string constructor: for $s in ("one", "two", "red", "blue")
return ``[`{$s}` fish]`` Are there any differences? |
The main motivation for this is making string constructor style constructs easier to read, per discussions on the #xpath-ng slack channel on Dec 18 (https://xmlcom.slack.com/archives/C01GVC3JLHE/p1608283860102200). The key difference in logic is that this processes entities while string constructors don't (although I'm open to making it work the same as string constuctors). -- The motivation for supporting entities was to a) keep the parallel with attribute/text value templates (as StringLiterals support entities), and b) keep the syntax/grammar simple (i.e. re-using the attribute syntax). Note: In that thread, Michael Kay proposed the |
I have implemented something like that In Xidel. I call them extended strings, and have the prefix x:
|
Thanks for the clarification; sounds helpful! |
Btw, I had suggested a bunch of them: https://www.w3.org/Bugs/Public/show_bug.cgi?id=29360 |
@rhdunn i wonder if there's a way to make the existing string constructors do what you want? For example, |
That's an interesting idea. The issue is with backward compatibility when a I wasn't at those discussions, so I can't make that call. Also, we now have implementation experience on string constructors in XQuery, and text value templates in XSLT. |
👍🏼✖️💯 for easy to use template strings! Would the below example render a JSON-ish representation of the map $m?
|
I am not sure that there is a significant difference. The minor difference is that in string constructors, { } are not special - when i proposed string constructors i had in mind a use case such as generating CSS or JavaScript with very occasional embedded values. We ended up with different (probably much better) syntax than i had proposed, after a lot more discussion than i had expected. Making \ special in XQuery or XPath should be avoided if possible - regular expressions are already hard enough, especially when the query is wholly or partly embedded e.g. in a PHP or Java or JavaScript string. map:for-each($m, function($k, $v) { But @benibela is doing a lot of complex string processing - or Xidel users are, rather - and have specific needs. |
The intention behind this idea is to make use of the existing attribute value template syntax and infrastructure to apply that to string literals. Entity processing is therefore the same, so "1&2" would be the string "1&2" (just like with current StringLiteral), but with this proposal, you could write |
What does one have to do in order to get literal curlies in attribute content, then?
|
Oh my @benibela what a thread! And I stepped into the trap of wanting single backticks not knowing what I got into ... |
To include curly brackets use e.g.
<a data-curly-brace="{ '{' }" />
i.e. the string value. The XSLT 3 specification doesn't seem to talk
about other ways to escape the braces.
…--
Liam Quin, https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
Barefoot Web-slave, antique illustrations: http://www.fromoldbooks.org
|
The below works in existdb
<a href="{{{{link}}}}">{{name}}</a> Analog to that we could have
to get to
|
Yes, XQuery supports https://www.w3.org/TR/xquery-30/#prod-xquery30-CommonContent |
I'm inclined to support this - mainly because the existing StringConstructor syntax in XQuery is hopelessly unmemorable and unreadable, and I don't want to introduce it to XPath or XSLT in its current form. I would go for using the syntax ${There were {$n} green bottles}. (The leading Within the outer curly braces, the rules are as for XSLT AVTs and TVTs. The only characters that need escaping are curly braces, which are escaped by doubling. What about |
I also see the risk of |
Would |
Regarding the use of |
When i first proposed this, i experimented with <<EOF....EOF (like the Unix shell, Perl, etc) and The I would like to see interpolated strings in XPath (i was surprised they only ended up in XQuery in fact; probably my fault for making the original proposal for XQuery). |
I agree with Liam: If we introduce yet another string template/constructor syntax, we'll need to justify why we provide different solutions (at least in XQuery) that are more or less identical. |
I really like the idea to create something that resembles an attribute value (like @rhdunn proposed). attr="{ expr }" T"{ expr }" |
A suggestion that tries to improve the StringConstructors in XQuery 3.1, rather than abandoning them and doing something completely unrelated. The current syntax is:
I'd suggest supplementing this with
so the spec example
simplifies to
In the simplified version, backticks and curly braces can be doubled to escape them. The content must be non-empty so |
I like this simplified proposal a lot. I assume (hope) that entity references in the original string are not going to be resolved? |
I like this as well. It's in line with the intent of my original proposal. |
That's a great proposal @michaelhkay |
Yes, yes, yes! |
The use case i wanted to solve with these string constructors was being
able to generate CSS, JavaScript, and other syntaxes containing curly
brackets, while still being able to interpolate values.
Certainly i have heard from people using them in this way.
It's true that embedding a `{ or `} is fiddly in the current mechanism
- e.g. can be done by breaking the string and joining it with a
literal, rather as one has to do to include ]]> in a CDATA section.
So although i like `...` as you propose, it doesn't meet the original
needs, so presumably both syntaxes would coexist?
…--
Liam Quin, https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
Barefoot Web-slave, antique illustrations: http://www.fromoldbooks.org
|
I propose resolution of this issue as follows: (a) the current StringConstructor in XQuery is retained unchanged, and remains XQuery-only. (b) the justification for introducing something new (if we need one) is that for many simple cases it is simpler, and more suitable for scenarios in which XPath is embedded in a language such as XSLT. It has drawbacks, however, when constructing text that is rich in curly braces, for example JSON, CSS, or Java code. Or for that matter, text containing backticks. (c) for both XPath and XQuery we introduce the new primary expression
The semantics are identical to XSLT Value Templates (XSLT 3.0 §5.6) with the additional rule that a fixed part must not contain an unescaped backtick, and a literal backtick can be expressed by doubling it. Note that this rule means that a StringTemplate cannot start with the sequence tick-tick-[, so there is no ambiguity with the existing StringConstructor syntax. |
The feature has now been implemented in the spec. |
A string value template (SVT) is a StringLiteral that supports enclosed expression values and entities. It is written as either
T"..."
orT'...'
, where theT
stands for "template".For instance, the following expression:
evaluates to the sequence
("one fish", "two fish", "red fish", "blue fish")
.Grammar
The text was updated successfully, but these errors were encountered: