This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
(This requirement is entered on behalf of Florent Georges <fgeorges@fgeorges.org>) I wonder if it would not be beneficial to define a binary output method in XSLT and XQuery Serialization 1.1 (or rather both methods hex and base64). It would be defined in a way similar to the text method, but requiring the string value to be a valid lexical hexBinary or base64Binary. XML databases have binary types, and some popular extensions produce binary "things". For instance, in EXPath the modules to create ZIP files or the module to perform HTTP requests, which use the serialization spec in a way consistent with the new fn:serialize(), but add binary support. Such new methods would give all of them a standard, common way to describe binary serialization.
(This reply is entered on behalf of Liam Quin <liam@w3.org>) If we want to write non-XML data, we should also be able to read non-XML data and process it. Let's process these at the same time.
One of the interesting application is the support for XML-based formats, isomorphic to certain binary formats, such as the .torrent file format (see also [1].) With the binary I/O available in XSLT, it may become quite simple to write conversion routines to and from the XML-based format. That being said, I somehow think that the binary output is more valuable than the binary input. Personally, I'd consider looking at binary(3tcl) [2] for some inspiration. [1] http://lhc.am-1.org/lhc//users/ivan_shmakov/notes/xml_.torrent_format/ [2] http://www.tcl.tk/man/tcl8.5/TclCmd/binary.htm
I think binary serialization only makes sense in the context of generally adding better support for binary data to XSLT and XQuery. It's unfortunate that the XML Schema binary datatypes are such a weak foundation for this. Having two data types, hexBinary and base64Binary, that are focused on the lexical representation of the data rather than the value space isn't a good starting point. Perhaps we should do the string/URI trick: define our functionality in terms of one of them (say hexBinary) and have automatic promotion for the other. Operators that are needed include concatenation and slicing (subsequence) of binary values; bitwise and/or/xor/not; conversion to/from a sequence of integers representing the individual bytes (or perhaps other units, such as 1-bit, 8-bit, 16-bit, 32-bit, 64-bit chunks); conversion to/from strings (specifying the character encoding). Then we need the ability to read binary files (unparsed-binary()) and to write binary files. It's not clear to me that writing binary files really comes under the heading of "serialization", but we might like to design it that way.
Just for reference on an existing approach - In eXist we have simply added the serialization method "binary". Of course we already have functions for reading binary documents, these produce an xs:base64Binary which is never actually realised (its a re-readable stream underneath), when you have the serialization method binary we return the raw binary underlying the xs:base64binary value. So far we have never been asked for operations to work with bytes, rather people so far have wanted to work at the granularity of Binary Documents in our experience.
Assigning to future requirements per Working Group decision (https://lists.w3.org/Archives/Member/w3c-xsl-query/2012Oct/0087.html).