- From: Michael Kay <mike@saxonica.com>
- Date: Sun, 18 Oct 2015 10:23:52 +0100
- To: Josh Spiegel <josh.spiegel@oracle.com>
- Cc: Michael Dyck <jmdyck@ibiblio.org>, public-xsl-query@w3.org
I’ve never taken very much interest in this. There doesn’t seem a consistent policy. The ‘||’ operator is treated differently from a call on fn:concat(), but direct element constructors are treated as “trivially equivalent” to computed element constructors. AttributeConstructors do have their own representation in XQueryX, rather than being turned into concat() expressions, and that seems the closest analogy to this case. Michael Kay Saxonica > On 16 Oct 2015, at 19:30, Josh Spiegel <josh.spiegel@oracle.com> wrote: > > > A new element might be nice for cases where the XQueryX is converted back to XQuery using the appendix B stylesheet. > > Thanks, > Josh > >> On Oct 16, 2015, at 10:18 AM, Michael Dyck <jmdyck@ibiblio.org> wrote: >> >> Should XQueryX have a custom element corresponding to StringConstructor, >> or should it just build an equivalent expression from pre-existing parts? >> >> -Michael >> > >
Received on Sunday, 18 October 2015 09:24:18 UTC