- From: Michael Dyck <jmdyck@ibiblio.org>
- Date: Wed, 16 Sep 2015 22:41:29 -0400
- To: public-xsl-query@w3.org
On 15-09-16 04:49 PM, Robie, Jonathan wrote:
>
> [201] StringTemplate ::= '<[' StringTemplateText ']>'
To me, the "Text" suffix suggests literal text, which is misleading.
Elsewhere in the grammar, in analogous spots, we use the suffix "Contents".
> [202] StringTemplateText ::= (StringTemplateChars,
> (StringTemplateExpr, StringTemplateChars)*)
Presumably you mean it without the commas. (Plus the outermost parens are
unnecessary.)
... ::= StringTemplateChars (StringTemplateExpr StringTemplateChars)*
> [nnn] StringTemplateChars ::= Char* - (Char* ('<{' | ']>') Char*))
Unbalanced parens, but the grammar software will take care of that.
> [nnn] StringTemplateExpr ::= '<{' Expr '}>'
Hm. Note that a StringTemplate actually *is* a kind of Expr, whereas a
StringTemplateExpr *isn't*. So I think these names could lead to confusion.
> An string template
s/An/A/
> can contain embedded expressions, which are called
> string template expressions.
Similar naming problem to StringTemplate vs StringTemplateExpr.
> The string value of each string template expression $e is computed
> using the expression string-join($e ! string(.), ' ').
> Thus, <[ <{ 1 to 3 }> ]> evaluates to the string "1 2 3".
> When a string template is evaluated, string template text is treated
> as literal text.
It's not entirely clear what that means. If, by "string template text", you
mean the query text parsed as StringTemplateText, then it's not true in
general.
> Line endings are processed as elsewhere in XQuery;
That's ambiguous, because there's at least two different ways that line
endings are processed. If you're thinking of A.2.3 End-of-Line Handling, you
could mention it, but note that nowhere else does. Also, note that A.2.3
processing is not performed on the value of a StringTemplate, but on the
characters of the query, before it's even parsed.
> no other processing is performed on string template text. Each string
> template expression is evaluated and converted to its string value,
> then concatenated with string value text
"string value text" ?
> to create one string, which is the value of the string template expression.
See, right there, in one sentence, "string template expression" used with
two different meanings.
>
> Note:
>
> In string template text, & is not recognized as special, and < is
> only recognized when immediately followed by "{". Thus, <[ < ]>
> evaluates to the string " < ", not the < character, and <[ <[ ]>
> evaluates to the string " <[ ".
It might help the reader to say:
... the 6-character string " < "
and
... the 4-character string " <[ "
> Example:
>
> for $s in ("one", "two", "red", "blue")
> return <[<{$s}> fish ]>
>
> evaluates to
>
> "one fish two fish red fish blue fish"
Well, I think it *evaluates* to:
( "one fish ", "two fish ", "red fish ", "blue fish ")
which (if that's the whole query) would get serialized to the above string.
> Example:
>
> Embedded expressions can contain string templates to created nested
> string templates.
s/created/create/
But string templates don't "create nested string templates", they create
string values.
> Example:
Duplicate "Example:" header.
> <[ <{ $i, <[ literal text ]>, $j, <[ more literal text ]> }> ]>
>
> If $i is 1 and $j is 2, then this evaluates to:
>
> " 1 literal text 2 more literal text"
I think that result is missing some blanks. But rather than change the
result, I think it would be clearer to change the query:
<[ <{ $i, <[literal text]>, $j, <[more literal text]> }>]>
-Michael
Received on Thursday, 17 September 2015 02:42:04 UTC