5771 2008-06-19 09:43:31 +0000 [FO] Feature request: get binary data from URI 2013-07-18 13:40:23 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 3.0 Working drafts PC Windows NT CLOSED INVALID P2 enhancement --- 1 tim mike abel.braaksma liam public-qt-comments oldest_to_newest 20592 0 tim 2008-06-19 09:43:31 +0000 RFC 2397 defines the 'data' URL scheme, which allows base 64 encoded binary data to be represented in a URI. This is commonly used in SVG to include binary image data. Might I suggest the addition of a function to retrieve data from a URI as xs:base64Binary? Perhaps something along the lines of fn:binary-data($uri as xs:string?) as xs:base64Binary? fn:binary-data-available($uri as xs:string?) as xs:boolean? following the pattern for fn:doc and fn:doc-available. 23916 1 liam 2009-02-24 22:14:49 +0000 You can do this today using existing string processing functions: cast the URI to a string, use substring-after to remove the "data:" and then process the base64 data as if from a string, e.g. with a base64Binary constructor. So, closed as WONTFIX; if you feel we're missing a reason why we need this, please reopen. Thanks! 23926 2 tim 2009-02-25 09:03:20 +0000 I think you may have misunderstood me. What I'm suggesting is reading data at a specified URL as binary data. e.g. binary-data('http://www.w3.org/Icons/w3c_main') As far as I am aware, the only functions which read external data are fn:doc, fn:collection and fn:unparsed-text. 23927 3 mike 2009-02-25 09:59:12 +0000 Well, that seems like a different requirement from reading URIs using the "data" scheme. Incidentally, XSLT has a function unparsed-text() for reading plain text files, there's no intrinsic reason why that shouldn't migrate into XQuery along with other XSLT functions that are going that way. I can see that unparsed-binary() would sometimes be useful too. My main reservation is that it would open up a whole new area for functions and operators dealing with binary data. For example, Saxon currently has extension functions to convert between xs:base64Binary/xs:hexBinary and xs:string/xs:byte*, in both directions, giving 8 functions in all. There have also been requests in the past for functions that do bitwise and/or/xor, or that test/set individual bits or bytes (though converting to xs:byte* is arguably a sufficient enabler for that). 23928 4 tim 2009-02-25 10:11:53 +0000 In my original post, I was suggesting this function as a means to allow the creation of 'data' scheme URIs, not reading them. Sorry for the confusion. I agree that there is quite a bit that _could_ be usefully added to aid manipulation of hexy/base64 binary data, e.g. an equivalent of substring. While many operations could be done using existing functions operating on the lexical representation of these types (i.e. cast as string), it would of course require a means to read binary data in the first place, hence the feature request. 23939 5 liam 2009-02-25 21:35:18 +0000 Closed as "INVALID". People can write image handling libraries, but let's not introduce such a thing a feature at a time. The Working Groups considered the original request, and today considered your clarification. We don't feel at this time that the work needed to expand handling of binary data is justified, particularly as we don't have clear use cases or examples. But if you end up developing such a library and it proves popular, it would quite likely be a candidate for standardisation in some future version of Functions and operators. The unparsed-text function is another matter, and we'll track that separately. 28284 6 mike 2009-10-12 22:30:02 +0000 Sicne the WG decided that this was out of scope for this version of the specification, and there has been no push-back, I am marking this as closed. Please feel free to reopen it if you think further discussion is needed. 90917 7 abel.braaksma 2013-07-18 13:40:23 +0000 Note for reference, after the F2F of February 2013, handling binary data has become a part of EXPath. As of March 5, 2013, it is a Candidate Module: http://expath.org/spec/binary/editor.