- From: Adam Retter <adam@exist-db.org>
- Date: Tue, 5 May 2015 10:11:08 +0100
- To: Christian Grün <christian.gruen@gmail.com>
- Cc: Michael Kay <mike@saxonica.com>, Florent Georges <fgeorges@fgeorges.org>, EXPath CG <public-expath@w3.org>
I think as the file module is so focused on file system operations, we would be better to use the HTTP Client module for this. On 5 May 2015 at 09:59, Christian Grün <christian.gruen@gmail.com> wrote: > I think this would require various changes in our current File Module > specification. For example, in Section 2.2 of the spec [1], it is > expected that "all paths are normalized to an implementation-defined > representation (which usually is the representation of the underlying > operating system)", and "An implementation may choose to raise > [file:invalid-path] if a path is invalid." Maybe we should even extend > this to something like "An implementation MUST raise an error if a > path is no valid file system path". > > I also don't know if we should really talk about "files" when > addressing remote data. A term like "resource" might be more general? > > Currently, the HTTP Client Module is probably the best alternative to > retrieve remote files [2]. In the current spec, however, it also > depends on the server what type the result will have. Beside that, the > result will always be wrapped into an XML response. @Florent: I > remember there have been efforts to provide a Version 2.0 of this > spec. Maybe some more functions could be added to the module to > simplify the retrieval of resources as xs:base64Binary? > > In Zorba and BaseX, there are additional modules for retrieving > resources for arbitrary URLs [3,4]. We could also think about making > these standard modules. > > Christian > > [1] http://expath.org/spec/file#file-paths > [2] http://expath.org/spec/http-client > [3] http://www.zorba.io/documentation/3.0/modules/zorba/io/fetch/ > [4] http://docs.basex.org/wiki/Fetch_Module > > > On Tue, May 5, 2015 at 10:39 AM, Michael Kay <mike@saxonica.com> wrote: >> I don’t think we can add things to FO 3.1 at this stage simply because we’ve identified a new requirement. >> >> To me the natural solution is to allow file:readBinary() (and analogous functions, presumably) to accept HTTP URIs as well as FILE URIs. >> >> Michael Kay >> Saxonica >> mike@saxonica.com >> +44 (0) 118 946 5893 >> >> >> >> >>> On 5 May 2015, at 09:18, Christian Grün <christian.gruen@gmail.com> wrote: >>> >>> As a fact, none of the functions of the File Module provides support >>> for HTTP URIs. But if it's not too late, fn:unparsed-binary could be >>> added to the XQFO 3.1 spec? Maybe this would also be your intention? >>> >>> >>> On Tue, May 5, 2015 at 10:06 AM, Michael Kay <mike@saxonica.com> wrote: >>>> There seems to be an omission in the FILE module: file:readBinary() will >>>> only read a file from filestore. We don’t seem to have any way to read a >>>> binary file from an HTTP URI. >>>> >>>> Michael Kay >>>> Saxonica >>>> mike@saxonica.com >>>> +44 (0) 118 946 5893 >> > -- Adam Retter eXist Developer { United Kingdom } adam@exist-db.org irc://irc.freenode.net/existdb
Received on Tuesday, 5 May 2015 09:11:35 UTC