This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 5771 - [FO] Feature request: get binary data from URI
Summary: [FO] Feature request: get binary data from URI
Status: CLOSED INVALID
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.0 (show other bugs)
Version: Working drafts
Hardware: PC Windows NT
: P2 enhancement
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-19 09:43 UTC by Tim Mills
Modified: 2013-07-18 13:40 UTC (History)
2 users (show)

See Also:


Attachments

Description Tim Mills 2008-06-19 09:43:31 UTC
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.
Comment 1 Liam R E Quin 2009-02-24 22:14:49 UTC
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!



Comment 2 Tim Mills 2009-02-25 09:03:20 UTC
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.

Comment 3 Michael Kay 2009-02-25 09:59:12 UTC
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).
Comment 4 Tim Mills 2009-02-25 10:11:53 UTC
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.
Comment 5 Liam R E Quin 2009-02-25 21:35:18 UTC
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.


Comment 6 Michael Kay 2009-10-12 22:30:02 UTC
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.
Comment 7 Abel Braaksma 2013-07-18 13:40:23 UTC
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.