Daniel Hartwig <mand...@gmail.com> writes: > On 24 February 2013 18:45, Mark H Weaver <m...@netris.org> wrote: >> I would argue that Absolute-URIs are more often appropriate in typical >> user code. The reason is that outside of URI-handling libraries, most >> code that deals with URIs simply use them as universal pointers, >> i.e. they implicitly assume that each URI is sufficient by itself to >> identify any resource in universe. > > Right. RFC 3986 makes a convincing argument for the new terminology. > These notes about usage also reflect the sentiment in that document. > > FWIW, I sat mostly on the fence, finally going away from URI-Reference > due to these concerns I expressed in an earlier email: >> The API seems less clean, and it is not immediately clear >> that uri? is not the top of the URI-like type hierarchy. The other >> functions only indicate “uri” in their name. I did not >> wish to introduce parallel “build-uri-reference”, etc. for each of >> these, and did consider adding #:reference? on some to select >> weaker validation. > > and looking at some other Scheme URI modules. > > However, having read over your comments I think that we could > reasonably get away with just introducing the procedures you mention > below and not bother about renaming (or duplicating) the field getters > to ‘uri-reference-path’ etc..
Hmm. The cleanest solution would probably be to duplicate the field getters, and make the 'uri-*' variants (e.g. 'uri-path') raise an error when applied to a relative reference. However, it's probably not that important, so if you think it's better to simply extend 'uri-path' etc to apply to all URI-References, I'm okay with that. >> Here's what I suggest: instead of extending 'string->uri' and >> 'build-uri' to produce relative URIs, rename those extended procedures >> 'string->uri-reference' and 'build-uri-reference'. These are long >> names, but that's okay because users should think twice before using >> them, and that's seldom needed. > > In your proposed solution, ‘uri?’ and ‘uri-reference?’ are the > predicates and they respond according to the RFC rather than internal > Guile details? What do you mean by "rather than internal Guile details"? Here's how I like to think about these types: URI-Reference is at the top of the type hierarchy, and URI (a.k.a. Absolute-URI) and Relative-Ref are subtypes. Furthermore, every URI-Reference is either an Absolute-URI or a Relative-Ref. In other words, if you create a URI-Reference that happens to be absolute, then you'll end up with a URI, in the same sense that if you create a complex number whose imaginary part happens to be exact zero, you'll end up with a real number. > That is: > > (uri? (string->uri-reference "http://example.net/";)) > => #t > (uri-reference? (string->uri-reference "http://example.net/";)) > => #t > (uri? (string->uri-reference "foo")) > => #f Yes. >> Then, we extend 'string->uri' and 'build-uri' in a different way: we >> extend them to handle relative references in their *inputs*, but >> continue to provide absolute *outputs*, by adding an optional keyword >> argument '#:base-uri'. This would make it easy to implement the >> simplest and safest strategy outlined above with a minimum of code >> changes. > > This strategy does reflect the recommendation of RFC 3986 to resolve > the references as they are read. Also an elegant API, as it > encourages immedately resolving uri-references and never creating (or > considering to create) the context-sensitive relative-refs. > >> >> What do you think? >> > > I quite like it, particularly the last part about #:base-uri. > > Ludo, I think this is basically what you were suggesting in the first place? > :-) Excellent! BTW, to be clear, I suggest that 'string->uri' and 'build-uri' should be guaranteed to produce Absolute-URIs. In other words, they should raise an error if not given enough information to produce an Absolute-URI. Does that make sense? Thanks again for your work on this :) Mark
