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. > >> 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. 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. Regards
