Hi Peter,

To answer your last point, I reworked the draft document to use language like "an &error exception is raised" (and to distinguish between error and assertion violation).

However in reading further about exceptions and conditions it seems I have confused the exception and the condition object. The language in the newest draft was mostly based on the first section of "https://www.scheme.com/tspl4/exceptions.html#./exceptions:s8" but I guess that &error, &assertion-violation &c. are really the condition type.

There is a section further up which states that implementations may not have access to R6RS conditions, which I think uses the correct language, but the procedure descriptions refer to &error &c. as an exception.

Anyway, I've tried my best to be really explicit about what is raised, and any irritants raised also.

For the function specification the signatures probably aren't that important given the language describing error-rasiing behaviour on input types now, so these can probably be deleted in a subsequent draft.

Thanks,
Duncan

> On 16 Jun 2026, at 15:39, Peter McGoron <xxxxxx@mcgoron.com> wrote:
>
> Hello,
>
> I admit I know very little about URIs and IRIs. I'll try to give the proposal a more in-depth read, but I have some minor style comments:
>
> 1. The light grey is a little difficult for me to read.
>
> 2. The function specification is a little confusing to read, because it looks like the functions are curried, when they are not.
>
> 3. Many of the instances of “it is an error” should be replaced with “assertion violation” (if it's the programmer's fault, for example using `iri-scheme` on a relative IRI) or “raises an &error exception” (if it's related to external data). This is the R6RS vocabulary for errors that raise exceptions and is more specific than R7RS’s “it is an error” which is undefined behavior.
>
> -- Peter McGoron
>