Hi, Daniel Hartwig <[email protected]> skribis:
> On 10 November 2012 04:52, Ludovic Courtès <[email protected]> wrote: >> Anyway, I think it’s fine if the documentation makes it clear whether >> functions expect absolute or relative URIs. WDYT? > > Yes. With the new predicates, it should be clear enough to use the > (pseudo-)type names in the usual scheme-doc way: > > -- Scheme Procedure: uri-resolve base-uri uri-reference > > and not need to repeat too much in the prose. Of course, doing so > when appropriate. I'll try to draft something sensible. Yes. >>> The build-uri validation works on the values before the <uri> object >>> is constructed, so I was just thinking of a separate build method with >>> different, less strict validation. >>> >>> We just have to think of <uri> and uri? as guile implementation >>> details, not RFC. Another option, is to rename <uri> to >>> <uri-reference>. Then uri? can mean the same as absolute-uri? (as per >>> the RFC). >> >> Out current URI objects are actually absolute URI references, right? In >> that case, we’ll indeed have to make ‘uri?’ synonymous with >> ‘absolute-uri?’, for backward compatibility. > > More-or-less, the only exception being when validation is disabled: > > scheme@(guile-user)> (uri? (build-uri #f #:path "foo" #:validate? #f)) > $1 = #t > > that object has no scheme, and is not an absolute-uri. This is a bit > of an edge case. Yes, but when the user sets #:validate? to #f, then they take the responsibility for anything that will happen. IOW, #:validate? #f allows users to forge broken URI objects, but that’s part of the contract anyway. > The current documentation only defines a URI as an absolute-uri and > does not talk about anything else. Most functions (uri->string, etc.) > will not work when passed something without a scheme. So I think your > suggestion is ok as any users of the current API will most certainly > be using only absolute-uri's. Good. So that means that URI refs can be added without introducing any incompatibility. Thanks, Ludo’.
