Excellent, I had overlooked this possibility, however - currently file:children and file:descendants (which are not part of the EXPath standard) do not support a file name pattern, nor do they support the deep flag. So addition of these two parameters would be a considerable improvement, but still do not offer the solution I would wish for, because I want (what I regard as) a key operation of XQuery (aggregated document access) to be represented in the most straightforward way. Concerning insistence on keeping to the XQuery standard, you must be indifferent to the following BaseX modules:

Archive Module                https://docs.basex.org/wiki/Archive_Module
Binary Module                 https://docs.basex.org/wiki/Binary_Module
Conversion Module             https://docs.basex.org/wiki/Conversion_Module
Cryptographic Module          https://docs.basex.org/wiki/Cryptographic_Module
CSV Module                    https://docs.basex.org/wiki/CSV_Module
Database Module               https://docs.basex.org/wiki/Database_Module
Geo Module                    https://docs.basex.org/wiki/Geo_Module
Hashing Module                https://docs.basex.org/wiki/Hashing_Module
HTML Module                   https://docs.basex.org/wiki/HTML_Module
Inspection Module             https://docs.basex.org/wiki/Inspection_Module
JSON Module                   https://docs.basex.org/wiki/JSON_Module
Lazy Module                   https://docs.basex.org/wiki/Lazy_Module
Process Module                https://docs.basex.org/wiki/Process_Module
Profiling Module              https://docs.basex.org/wiki/Profiling_Module
Random Module                 https://docs.basex.org/wiki/Random_Module
Request Module                https://docs.basex.org/wiki/Request_Module
SQL Module                    https://docs.basex.org/wiki/SQL_Module
Strings Module                https://docs.basex.org/wiki/Strings_Module
Validation Module             https://docs.basex.org/wiki/Validation_Module
Web Module                    https://docs.basex.org/wiki/Web_Module
XQuery Module                 https://docs.basex.org/wiki/XQuery_Module



-

Am Freitag, 11. Februar 2022, 23:05:30 MEZ hat Majewski, Steven Dennis (sdm7g) <sdm7g@virginia.edu> Folgendes geschrieben:



Unnecessary and non-standard ( file: functions are not XQuery standard, but are EXPath functions).  

Use:  file:children( file:resolve-path( $folder ) )

If you give file:children an absolute path, that will be included in results, so just resolve the relative folder path first. 

— Steve M. 


On Feb 11, 2022, at 1:40 PM, Hans-Juergen Rennau <hrennau@yahoo.de> wrote:

Dear BaseX people,

I have a feature request:

a function which does the same as file:list, but returns the full paths. (In the explanation, I call it "file:list2")

Rationale:
(a) It is the full paths what we need in order to parse the files (doc(), json:doc(), csv:doc(), html:doc()).
(b) The combination of file listing and parsing in a single expression is of matchless elegance and expressiveness
Just think about how we can extend this into a single list+parse+navigate+report expression, like:

file:list2($folder, true(), $fname) ! doc(.) ! //returnCode[. ne 0]/concat(base-uri(.), ': ', .)

(Wow! Is there any language or tool competing with this compactness and readability?)

Currently, if I don't overlook something, I have to do this:
   file:list($dir, false(), $fname) ! concat($dir, '/', .) ! doc(.) => count()

I emphasize the psychological aspect. Every time I have the pleasure to give a workshop about XQuery, I show off how elegant it is to parse a whole file system tree into a forest of nodes in a single expression. And I am always embarrassed about this clumsy fumbling montage of a path. It's as if Mozart had fallen asleep while writing his xquery sonata, knocked over the inkwell and now there is this splash smeared out on the score. You would be my heroes if you can spare us that.

Kind regards,
Hans-Jürgen