Re: Thinking about fn:build-uri (PR #1388)

Reece Dunn <msclrhd@googlemail.com> writes:
> On Mon, 2 Sept 2024 at 17:13, Christian Grün <cg@basex.org> wrote:
>
>  What do others think: Should we keep or drop the custom separator options?
>
> I'd prefer to keep this as close to just the URI specs (RFC, WHATWG) as possible with minimal processing.

I think that’s a vote in favor of dropping the path and query separator options.

> Ideally an implementor should be able to implement this using the native language API (e.g. URI on Java) and then just handle the translation to/from an XPath/XQuery map.

Unfortunately, these functions are really about string manipulation, not URI processing. We’re explicitly trying to address “uri-like” strings that Java.net.URI would reject out-of-hand.

fn:parse-uri answers the question, “given this string that purports to be a URI, what parts can we identify”: scheme, path, path segments, etc.

fn:build-uri is really just a utility function to do the reverse. Given a map of URI parts, put a URI together. It’s probably a whole lot easier to do that in your hand-rolled XQuery than the parsing. But it seems churlish to provide a parse function without a build function.

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica