Jennie, the lighter variant has been discussed with Peter. Please ask him. The rationale behind execute at "URI" { f() } exactly is that we can save braces in the case where the URI is specificied in the literal. No parsing ambiguities here. Making this execute at { "URI" } { f() } does not buy us anything, obviously. Think of it this way: it's just like an element constructor that uses a literal QName: no curly braces around foo needed in element foo { ... } On Nov 8, 2006, 1:31 AM, Ying Zhang wrote with possible deletions:
[...] Further, I'm wondering how useful it is to add this lighter variant explicitly. Isn't 'URILiteral' just an 'Expr'?
No, an URILiteral is a very *specific* expression -- sufficiently specific to remove any ambiguity during parsing.
Do you want to add this variant because the time needed for compilation can then be significantly reduced if the URI is a simple string, instead of a complex Expr?
Not at all -- just notational convenience. If you don't like the lighter variant, you are welcome to continue to use the equivalent execute at { "URI" } { f() } which will work also in the presence of literal URIs. Cheers, --Teggy -- | Torsten Grust | torsten.grust@gmail.com