Re: URI Functions

All,

As Steven said we'll discuss this during an upcoming all, but a few
thoughts:

- I see some benefits of using a `map()`: there is only one function to
add, and the result can easily scale to adding more values.

- Even when using XPath 2.0, a subset of the `map:` functions can be
supported and XForms could mandate that. We do this in our implementation,
without supporting the native literal syntax for maps.

- I am less of a fan of using a result XML document. What we have here is
a name/value mapping, and using XML for that is pretty heavy. It would
work, of course.

- There are also drawbacks of using maps. Specifically, they are entirely
untyped. If you make a typo in a key name, your XPath processor/compiler
can catch that. If you write:

    map:get($map, 'foo')

   and `foo` is not a member of the map, you are out of luck if it returns
an empty sequence. While:

    get-foo($uri)

   will catch the attention of the XPath processor.

   The same goes for accessing an XML document with the URI parts. Your
XPath `/*/foo` will not be checked. I realize that this is the norm with
XPath.

-Erik

On Tue, Aug 28, 2018 at 1:17 PM Andreas Mixich <mixich.andreas@gmail.com>
wrote:

> On Tue, Aug 28, 2018 at 2:22 PM Steven Pemberton <steven.pemberton@cwi.nl>
> wrote:
>
>> Hi gang,
>>
>> Yesterday I received a mail from someone enquiring about the URI
>> Functions.
>>
>
> That was me. My message to the list, which I have written in the late
> morning, got
> caught by the list-processor, awaiting permission to archive and thus post
> the mail to
> the list. That's why we now have two threads regarding this topic. I am
> sorry, but I just
> saw the confirm message in the evening. Just disregard the other thread,
> though
> Liam has come up with some remarks in reply to it.
>
>
>> Since we already have a parse() function,
>>
>>
> [...]
>
> A call like
>>
>>    parse-IRI("
>> https://username:password@example.org:8080/pages/order?id=42&n1=v11#content
>> ")
>>
>> could produce one of the following document nodes:
>>
>>
> I like the idea. Though, I still think, a single IRI function, that
> componentizes an IRI should go into any
> future XPath spec. But as I have laid out in my other message to this
> list, that may take a long time,
> if ever, and so this seems a very viable approach.
>
> I like the combination of the first proposal with the third one (for the
> query part) the most, since every
> component gets its logical counterpart by way of an element. If you put
> 'username:password' together,
> that's one additional step the user of such a function would need to do.
> Also, if named 'IRI' we must
> understand, that URNs belong into this group as well, but are disjoint
> with URLs. The URN RFC has
> seen a quite extensive update in 2017 by means of RFC 8141 (
> https://tools.ietf.org/html/rfc8141)
>
> <iri>
>   <scheme>https</scheme>            <!-- is always 'urn' for URN -->
>   <path>/pages/order</path>         <!-- could be mapped to NSS -->
>   <query name="id">42</query>       <!-- seems mappable to q-component -->
>   <query name="n1">v11</query>
>   <fragmet>content</fragmet>        <!-- mappable to f-component -->
>   <user>user</user>                 <!-- no special equivalence for URN -->
>   <password>password</password>     <!-- no special equivalence for URN -->
>   <host>example.org</host>          <!-- disjoint with URN -->
>   <port>8080</port>                 <!-- disjoint with URN -->
>   <filename>index.html</filename>   <!-- no special equivalence for URN -->
>   <!-- URN components follow -->
>   <nid>example</nid>                <!-- the 'authority' component for URN
> -->
>   <nss>some-specific-string</nss>   <!-- the 'path' component for URN -->
>   <r-component>c901</r-component>   <!-- R esource Component -->
>   <q-component>sample</q-component> <!-- Q uery Component -->
>   <f-component>id11.1</f-component> <!-- F ragment Component -->
>   <is-urn>true|false</is-urn>       <!-- some sugar, could be an attribute
> -->
>                                     <!-- (@type="url|urn")to
> document-node, -->
>                                     <!-- if both IRI types could be merged
> -->
> </iri>
>
> There is some overlap for 'query/q-component', 'fragment/f-component' and
> 'nid', which designates the 'authority' but is very different from the URL.
> 'nss' could be compared to 'path' + 'filename'. Since URN and URL are
> disjoint
> I think, it may be wisest, to keep the element names separate, since it
> won't
> be possible, to join them. 'authority', according to RFC 3986, consists of
> 'user:password@host:port' while for an NID it is a single string-value.
>
> --
> Minden jót, all the best, Alles Gute,
> Andreas Mixich
>