Saxon » SaxonJS

Worked around like this:

<xsl:variable name="js-statement" as="element()">
    <root statement="{{ &quot;Q{{&ldt;}}base&quot;: &quot;{$ldt:base}&quot; }}"/>
</xsl:variable>
<xsl:variable name="stylesheet-params" select="ixsl:eval(string($js-statement/@statement))"/>

Can you help me understand what's motivating this example?

If stylesheet-params was an ordinary XPath map, you could just use XSLT functions or instructions to change it. Instead, you appear to have constructed a plain-old-JavaScript object on which you want to set a key named "Q{https://www.w3.org/ns/ldt#}base" (do I have that right)?

What are you subsequently going to do with stylesheet-params that requires it to be a JavaScript object not an XPath map?

I'm passing the $stylesheet-params map to a JS listener function which ten passes it to SaxonJS.transform({ "stylesheetParams": { stylesheetParams });.

In general I think it's a problem that properties with dots in their names cannot be used with ixsl:set-property/@name, because there certainly are situations where this is required and escaping with a different char is not an option. In my case most of such propertes are URLs.

I agree the uncontrolled interpolation of "."s is a problem. I've imagined a lexical hack to work around it, but I'm waiting to see if my colleagues react in horror :-)

Basically, I'm thinking that if you said name="[a.b.c]" we'd use the property name inside the square brackets without interpolating the dots. That, alas, wouldn't help if the name of the property you wanted to set was literally "[a.b.c]" so it's still imperfect.

Perhaps

name="`a.b.c`"

allowing a backtick within the property name to be escaped as a double-back-tick?

Yes, that works for me.

name="a.b.c" ==> $object["a"]["b"]["c"]
name="`a.b.c`" ==> $object["a.b.c"]
name="`a``b.c`" ==> $object["a`b.c"]

Mismatched flavors of backtick would be errors or just produce whatever results they produce.

Right. It was sort of a toss-up in my mind about which was better, a new attribute (which would have to have a new name, which would have to be exclusive of the existing attribute, which would require changes in both compilers, etc.) or some sort of lexical trick.

I was persuaded by the lexical technique partly because it was somewhat easier and simpler, but also because it's more versatile. A new attribute would be an all-or-nothing solution. The lexical approach means that you can be selective about which "."s are treated as dividers.

It did occur to me that we could have said that you can use "\." to escape the following period and "\\" to insert a literal backslash. But that would introduce questions about what backslash in front of other characters means and I backed slowly away from that idea.

Thanks Norm. I just want to make sure that I'm getting the new syntax right. Would it look like this?

<xsl:variable name="url" select="'https://saxonica.plan.io/issues/5673'" as="xs:string"/>
<ixsl:set-property name="{'`' || $url || '`'}" select="..." object="..."/>

Yes. If you're doing this in several places, you might get some milage out of a function:

<ixsl:set-property name="{f:escape-name($url)}" select="..." object="..."/>

for example

<xsl:function name="f:escape-name" as="xs:string">
  <xsl:param name="name" as="xs:string"/>
  <xsl:sequence select="'`'||replace($name, '`', '``')||'`'"/>
</xsl:function>

See also #5714 for documentation fixes to be applied.