Open AlainCouthures opened 7 years ago
We should split this issue in multiple discussion See #5 for discussion about node creation
What's wrong with updating the EXPath specs to accept dynamically constructed maps / arrays as inputs as well as XML elements?
Updating the EXPath specs with support for maps and arrays should be considered as a specific workaround.
Dynamically created nodes can be useful in complex expressions. In XPath library, for example, fn:analyze-string() does!
It sounds to me as a great paradox to have to use maps and arrays instead of XML nodes...
XML is cool, but unfortunately the reality is that it turns a lot of developers off. Passing complex content around in the form maps and arrays which can be dynamically constructed like you can in JavaScript is less verbose than dynamically constructing XML, things get even worse when namespaces are concerned.
XPath and XQuery look similar and, in fact, XQuery is a superset. Why such a distinction has to be done?
XPath requires an host language while XQuery does not. That is why it is possible to write an XQuery prolog, for example, to define namespaces, variables, functions,...
But there are also XQuery-only features to be used within expressions, for example, FLWOR expressions for XQuery while just For and Let expressions for XPath. Why this? Is it because host languages have to provide those features? For sure, XSLT does this but XForms does not and might specify yet another syntax for this... Why should Switch and Try/Catch expressions be not supported in XPath too?
Another big XQuery-only feature is the capability for creating nodes. With XPath-only, it is not possible to have temporary nodes for processing. The http:send-request() EXPath function cannot be used within XPath because of its parameters being nodes (fn:serialize() now allows a map as parameter)! The xf:element() XForms 2.0 function sounds like an abusive workaround for the lack of element constructor in XPath!
What do you think?