- From: Mark D. Anderson <mda@discerning.com>
- Date: Mon, 16 Aug 2004 14:07:32 -0700
- To: public-qt-comments@w3.org
On Mon, 16 Aug 2004 14:40:00 +0100, "Michael Kay" <mhk@mhk.me.uk> said: > Generally, the WGs aren't disposed to consider requests for new features > at the moment. I understand, though on the receiving side there isn't much motivation to study the drafts closely until they begin to congeal. I suppose it is also too late then to ask for declared default values for function arguments? :) That is another example of something in XSLT not in XQuery, but an example where it is even harder to attribute the difference to some putative distinction between transforming and querying..... > The functionality of your fn:match is a subset of what can be achieved by > xsl:analyze-string in XSLT 2.0. XQuery WG decided that this level of > capability went beyond what was needed in XQuery 1.0. I think most use > cases > for this kind of functionality require the construction of new elements > to > contain matched substrings, which your design does not readily allow. It isn't builtin, but it isn't hard. After all, fn:match is intended to work similarly to the perl "m//", which some people have found to be useful :). non-looping example: let $matches = fn:match("alpha/beta/gamma", "(\w+)/.*/(\w+)") return <first>{$matches[1]}</first><second>{$matches[2]}</second> looping example: for $matches in fn:match(fn:doc('stuff.xml'), "(\w+)/.*/(\w+)", "g") return <match><first>{$matches[1]}</first><second>{$matches[2]}</second></match> I don't really see how this is much different in power than: <xsl:analyze-string select="document('stuff.xml')" regex="(\w+)/.*/(\w+)"> <xsl:matching-substring> <match> <first><xsl:value-of select="regexp-group(1)"/></first> <second><xsl:value-of select="regexp-group(2)"/></second> </match> </xsl:matching-substring> </xsl:analyze-string> > Your fn:apply is a simple (in fact, simplistic) solution to the need for > higher-order functions. The idea here is that fn:apply and fn:call would work similarly to apply and funcall in lisp, or apply and call in ecmascript, etc. There is a history for these being useful primitives that far exceeds XML in age. And it is certainly more controllable than a fn:eval(), which I am not appealing for.... > The WGs have decided not to do higher-order > functions this time around because of the complexity involved in getting > them to work in a way that doesn't break the type system. Hmmm, if you say so. > I think you'll > find that a majority of the WG is opposed to a solution like this that > might > meet 80% of the requirement, but is essentially slipping in a fundamental > language feature by the back door. It is certainly a fundamental feature. As for percentage of the requirements, I think it would be better off than XQuery regular expressions currently are.... -mda
Received on Monday, 16 August 2004 21:07:49 UTC