This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Wouldn't it be helpful, and symmetric, to have an function in the specification for decoding URIs? fn:decode-uri($uri-part as xs:string?) as xs:string I have seen that existing XQuery implementations already provide something equivalent: http://exist-db.org/exist/functions/xmldb/decode-uri http://www.zorba-xquery.com/html/modules/zorba/xdm/atomic/uri Decoding a URI via plain XQuery feels like a pretty tedious job, and I think it shouldn't be too hard to add the functionality to others implementations, so I'm wondering why this function hasn't made it to the standard yet. I have just found two discussions that also seem to focus on this issue.. http://markmail.org/thread/knd246eiayderbd6#query:+page:1+mid:knd246eiayderbd6+state:results http://markmail.org/thread/nt3hjtdizvz2ltvx#query:+page:1+mid:nt3hjtdizvz2ltvx+state:results ..but the argument "difficulty in the detail of specifying it", as Michael Kay put it, didn't really convince me, because functions like format-date() appear much more sophisticated to me. Regarding the use cases, I have one for myself, and the existing implementations and discussions seem to prove that there is some need. Sorry for bothering, thanks for reading, Hannes
The WG looked at this last week. There is some sympathy with the requirement, but we're at a stage of development where all requests for new features are being parked in a shopping list for a post-3.0 release, currently labelled 3.1. On the substance, I do know that it isn't going to be easy - the current batch of functions, iri-to-uri, encode-for-uri, and escape-html-uri - went through many iterations before we got them right, and accounted for well more than their fair share of comments and bugs. Even their names reflect the tortuous process we went through. We will have many questions to consider, for example what to do when % is not followed by two hex digits, and what to do when encoded URIs contain percent-escaped characters such as "/", where putting the "/" into the decoded value is unlikely to yield a string that serves any useful purpose. I think it's because these questions looked difficult that the function was not present in 2.0.
Thanks a lot for discussing my proposal, Michael. I'll be excited to see 3.1 evolve.
Assigning to future requirements per Working Group decision (https://lists.w3.org/Archives/Member/w3c-xsl-query/2012Oct/0087.html).
I came across some rumours that this functionality will also be somehow included in one of the future BaseX releases. Too much demand to ignore it ... Are you still planing to make it a part of XQuery 3.1?