W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2012

[Bug 18907] New: Decode URIs

From: <bugzilla@jessica.w3.org>
Date: Tue, 18 Sep 2012 12:15:50 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-18907-523@http.www.w3.org/Bugs/Public/>

           Summary: Decode URIs
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Functions and Operators 3.0
        AssignedTo: mike@saxonica.com
        ReportedBy: hannesbauer@yahoo.com
         QAContact: public-qt-comments@w3.org

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


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..


..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,

Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 18 September 2012 12:15:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:39 UTC