Re: URI Functions

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